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NATIONAL CYBERSECURITY CENTER OF EXCELLENCE 


The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards 
and Technology (NIST) addresses businesses' most pressing cybersecurity problems with 
practical, standards-based solutions using commercially available technologies. The NCCoE 
collaborates with industry, academic, and government experts to build modular, open, end-to- 
end reference designs that are broadly applicable and repeatable. The center's work results in 
publicly available NIST Cybersecurity Practice Guides, Special Publication Series 1800, that 
provide users with the materials lists, configuration files, and other information they need to 
adopt a similar approach. 

To learn more about the NCCoE, visit http://nccoe.nist.gov. To learn more about NIST, visit 

http://www.nist.gov. 

NIST CYBERSECURITY PRACTICE GUIDES 

NIST Cybersecurity Practice Guides (Special Publication Series 1800) target specific cybersecurity 
challenges in the public and private sectors. They are practical, user-friendly guides that facilitate 
the adoption of standards-based approaches to cybersecurity. They show members of the 
information security community how to implement example solutions that help them align more 
easily with relevant standards and best practices. 

The documents in this series describe example implementations of cybersecurity practices that 
businesses and other organizations may voluntarily adopt. The documents in this series do not 
describe regulations or mandatory practices, nor do they carry statutory authority. 
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3 Executive Summary 

4 ■ Both public and private sector business operations are heavily reliant on electronic mail (email) 

5 exchanges but the integrity of these transactions is often at risk, including financial and other 

6 proprietary information as well as the privacy of employees and clients. 

7 ■ Protocols such as Transport Layer Security (TLS), Secure/Multipurpose Internet Mail Extensions (S/ 

8 MIME), Domain Name System Security Extensions (DNSSEC), and Domain Name System (DNS) 

9 Authentication of Named Entities (DANE) exist and are capable of providing needed email security 

10 and privacy protection. 

11 ■ Impediments such as the absence of comprehensive configuration instructions for a composed set of 

12 mail client, mail transfer agents, and DNS security components, absence of resource guides to easily 

13 implemented software libraries and software applications for system administrators, and functional 
characteristics of security applications that negatively impact the performance of email systems have 

is limited adoption of these existing security and privacy protocols. 

1 6 ■ Operating email systems without employing available security and privacy protocols increases the 

17 opportunities for attackers to breach sensitive enterprise information by introducing false addresses 

1 8 into mail messages, disrupting secure communication signaling, and improving the probability of 

19 successfully inducing enterprise users to open malicious attachments - still the most common method 

20 for introducing malware and breaching enterprise systems. 

21 ■ The National Cybersecurity Center of Excellence (NCCoE) developed a set of example DNS-based 

22 email security solutions that organizations can use to facilitate implementation of security and privacy 

23 protocols, thus reducing the likelihood of a data breach. The solution sets include tools that support 

24 installation and set-up of trustworthy email systems. 

25 ■ The security characteristics in this guide are informed by guidance and best practices from standards 

26 organizations. How the solution set addresses security requirements and best practices is addressed 

27 in a volume that includes the security approach, architecture, and security characteristics. 

28 ■ The NCCoE's approach uses both open source and commercially available products that can be 

29 included alongside current mail products in existing infrastructure. 

30 ■ The example solution is described in a "How To" guide that shows how to implement a set of 

31 standards-based, commercially available cybersecurity technologies in the real world. The guide will 

32 help organizations utilize technologies to reduce the risk of untrustworthy email, while saving them 

33 research and proof of concept costs. 



34 THE CHALLENGE 


35 Whether the security service desired is authentication of the source of an email message or assurance 

36 that the message has not been altered by or disclosed to an unauthorized party, organizations must 

37 employ some cryptographic protection mechanism. Economies of scale and a need for uniform security 

38 implementation drive most enterprises to rely on mail servers and/or Internet service providers (ISPs) to 

39 provide security to all members of an enterprise. Many current server-based email security mechanisms 

40 are vulnerable to, and have been defeated by, attacks on the integrity of the cryptographic 

41 implementations on which they depend. The consequences of these vulnerabilities frequently involve 

42 unauthorized parties being able to read or modify supposedly secure information, or to use email as a 

43 vector for inserting malware into the system in order to gain access to enterprise systems or information. 

44 Protocols exist that are capable of providing needed email security and privacy, but impediments such as 

45 unavailability of easily implemented software libraries and software applications characteristics that 

46 complicate operation of email systems have limited adoption of existing security and privacy protocols. 

47 THE SOLUTION 

48 The Domain Name System-Based Security for Electronic Mail (Email) project has produced a proof of 

49 concept security platform that demonstrates trustworthy email exchanges across organizational 

so boundaries. The goals of the project include authentication of mail servers, signing and encryption of 

51 email, and binding cryptographic key certificates to the servers. The Domain Name System Security 

52 Extension (DNSSEC) protocol is used to authenticate server addresses and certificates used for Transport 

53 Layer Security (TLS) to DNS names. The business value of the security platform demonstrated by this 

54 project includes improved privacy and security protection for users' operations and improved support for 

55 implementation and use of the protection technologies. The platform also expands the set of available 

56 DNS security applications and encourages wider implementation of DNSSEC, TLS and S/MIME to protect 

57 internet communications. 

58 Project deliverables include: 

59 ■ demonstration prototypes of DNS-based secure email platforms 

60 ■ this publicly available NIST Cybersecurity Practice Guide that explains how to employ the platform(s) 

61 to meet industry security and privacy best practices as well as requirements for federal government 

62 agencies 

63 ■ platform documentation necessary to efficiently compose a DNS-based email security platform from 

64 off-the-shelf components 

65 ■ recommendations for effective implementation in a manner that is consistent with applicable 

66 standards documentation 


e? Approach 

68 The secure email project involves composition of a variety of components that have been provided by a 

69 number of different technology providers, including Microsoft Corporation, the Internet Systems 

70 Consortium, Secure64, Fraunhofer IAO, and Stichting NLnet Laboratories. Each of these collaborators has 

71 entered into a Cooperative Research and Development Agreement (CRADA) with NIST to participate in 

72 this consortium effort. These components include client systems, DNS/DNSSEC services, mail transfer 

73 agents (MTA), and certificate sources. 

74 We demonstrate how security can be supported through standards-based configuration and operation 

75 DNS servers, electronic mail applications and MTAs in a manner that supports trustworthy email by the 

76 organization. 

77 The guide: 


2 


78 ■ identifies the security characteristics needed to sufficiently reduce the risks to information exchanged 

79 by email 

so ■ maps security characteristics to standards and best practices from NIST and other organizations 

si ■ describes a detailed example solution, along with instructions for implementers and security 

82 engineers on efficiently installing, configuring, and integrating the solution into existing IT 

83 infrastructures 

84 ■ provides an example solution that is operationally practical and evaluates the performance of the 

85 solution in real-world scenarios 

86 BENEFITS 

8 ? Our example solution has several benefits, including the following: 

88 ■ reduces risk so that employees are able to exchange personal and enterprise information via email 

89 with significantly reduced risk of disclosure or compromise 

90 ■ enables the use of existing security protocols more efficiently and with minimal impact to email 

91 service performance 

92 ■ integrates capabilities into various server and client IT infrastructure environments 

93 ■ enhances visibility for system administrators into email security events, providing for recognition of 

94 authentication failures that could result in device and data compromises 

95 ■ implements both commercial and open source industry standard network and email security controls 

96 reducing long term costs and decreasing the risk of vendor lock-in 

97 ■ can be extended to other enterprise information exchange technologies that are growing in use (e.g., 

98 text messages, chat) 

99 TECHNOLOGY PARTNERS AND COLLABORATORS 

iooThe technology vendors who participated in this project submitted their capabilities in response to a call 
ioi in the Federal Register. Companies with relevant products were invited to sign a Cooperative Research and 
io: Development Agreement with NIST, allowing them to participate in a consortium to build this example 

103 solution. We worked with: 

104 ■ Microsoft Corporation 

105 ■ NLnet Laboratories 

106 ■ Secure64 

107 ■ Internet Systems Consortium 

108 ■ Fraunhofer IAO 
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,09 SHARE YOUR FEEDBACK 


no You can get the guide through the NCCoE web site, http://nccoe.nist.gov. Help us make it better by 
in sharing your thoughts with us as you review the guide. If you adopt this solution for your own 
112 organization, share your experience and advice with us. We recognize that technical solutions alone will 
in not fully enable the benefits of our solution, so we encourage organizations to share lessons learned and 
ii4 best practices for transforming the business processes associated with implementing it. 

ns ■ email dns-email-nccoe@nist.gov 

116 ■ join our Community of Interest to offer your insights and expertise; email us at dns-email- 

117 nccoe@nist.gov 

ns To learn more by arranging a demonstration of this reference solution, contacting us at dns-email- 
ii9 nccoe@nist.gov. 


The National Cybersecurity Center of Excellence at the National Institute of 
Standards and Technology addresses businesses' most pressing cybersecurity 
problems with practical, standards-based example solutions using commercially 
available technologies. As the U.S. national lab for cybersecurity, the NCCoE 
seeks problems that are applicable to whole sectors, or across sectors. The 
center's work results in publicly available NIST Cybersecurity Practice Guides 
that provide modular, open, end-to-end reference designs. 


LEARN MORE 

http://nccoe.nist.gov 

ARRANGE A DEMONSTRATION 
nccoe@nist.gov 

301-975-0200 
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The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards 
and Technology (NIST) addresses businesses' most pressing cybersecurity problems with 
practical, standards-based solutions using commercially available technologies. The NCCoE 
collaborates with industry, academic, and government experts to build modular, open, end-to- 
end reference designs that are broadly applicable and repeatable. The center's work results in 
publicly available NIST Cybersecurity Practice Guides, Special Publication Series 1800, that 
provide users with the materials lists, configuration files, and other information they need to 
adopt a similar approach. 

To learn more about the NCCoE, visit http://nccoe.nist.gov. To learn more about NIST, visit 

http://www.nist.gov. 

NIST CYBERSECURITY PRACTICE GUIDES 

NIST Cybersecurity Practice Guides (Special Publication Series 1800) target specific cybersecurity 
challenges in the public and private sectors. They are practical, user-friendly guides that 
facilitate the adoption of standards-based approaches to cybersecurity. They show members of 
the information security community how to implement example solutions that help them align 
more easily with relevant standards and best practices. 

The documents in this series describe example implementations of cybersecurity practices that 
businesses and other organizations may voluntarily adopt. The documents in this series do not 
describe regulations or mandatory practices, nor do they carry statutory authority. 

ABSTRACT 

This document describes a security platform for trustworthy email exchanges across 
organizational boundaries. The project includes reliable authentication of mail servers, digital 
signature and encryption of email, and binding cryptographic key certificates to sources and 
servers. The example solutions and architectures presented here are based upon standards- 
based open-source and commercially available products. 
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Chapter 1. Summary 


This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide 
addresses the challenge of providing digital signature technologies to provide authentication 
and integrity protection for electronic mail (email) on an end-to-end basis, and confidentiality 
protection for email in transit between organizations. It implements and follows 
recommendations of NIST Special Publication 800-177 (SP 800-177), Trustworthy Email. 
Detailed protocol information and implementation details are provided in SP 800-177. Domain 
Name System 1 protection features are consistent with SP 800-81-2, Secure Domain Name 
System (DNS) Deployment Guide. 

The NIST Special Publication 1800-6 series of documents contain: 

■ rationale for and descriptions of a Domain Name System-Based (DNS-Based) Electronic Mail 
(Email) Security platform that permits trustworthy email exchanges across organizational 
boundaries and 

■ a series of How-To Guides, including instructions for installation and configuration of the 
necessary services, that show system administrators and security engineers how to achieve 
similar outcomes 

The solutions and architectures presented are built upon standards-based, commercially 
available products. These solutions can be used by any organization deploying email services 
that is willing to implement certificate-based cryptographic key management and DNS Security 
Extensions (DNSSEC) 2 . Interoperable solutions are provided that are available from different 
types of sources (e.g., both commercial and open source products) and function in different 
operating systems environments. 

This summary section describes the challenge addressed by this Volume B (Approach, 
Architecture, and Security Characteristics ); describes the solution demonstrated to address the 
challenge; benefits of the demonstrated solution; lists the technology partners that 
participated in building, demonstrating, and documenting the solution; and explains how to 
provide feedback on this guide. Section 2, How to Use This Guide explains how each volume of 
the guide may be used by business decision makers, program managers, and Information 
Technology (IT) professionals such as systems administrators; and Section 3, Introduction 
provides a high-level project overview. Section 4, Approach provides a more detailed treatment 
of the scope of the project, describes the assumptions on which security platform development 
was based, describes the risk assessment that informed platform development, and describes 
the technologies and components that were provided by industry collaborators to enable 
platform development. Section 5, Architecture describes the usage scenarios supported by 
project security platforms, including Cybersecurity Framework 3 functions supported by each 
collaborator-contributed component. Section 6, Outcome describes any changes in users' mail 
processing experience imposed by the additional security functionality, and summarizes 
changes to systems administrators' experiences with respect to integrating the new capabilities 
into their systems and in systems operations and maintenance. Section 7, Evaluation 
summarizes the test sequences that were employed to demonstrate security platform services, 
the Cybersecurity Framework functions to which each test sequence is relevant, the NIST SP 
800-53-4 controls that applied to the functions being demonstrated, and an overview of 


1. RFC 1591, Domain Name System Structure and Delegation 

2. RFC 4033, DNS Security Introduction and Requirements 

3. Framework for Improving Critical Infrastructure Cybersecurity, Version 1.0, National Institute 
of Standards and Technology February 12, 2014 http://www.nist.gov/cyberframework/up- 
load/cybersecurity-framework-021214.pdf 
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Chapter 1. Summary 


platform performance in each of the two applications scenarios demonstrated. Section 8, 
Future Build Considerations is a brief treatment of other applications that might be explored in 
the future in demonstrating the advantages of broader DNS security adoption. Appendices are 
provided for acronyms, references, and a mapping of the DNS-Based Email Security project to 
the Cybersecurity Framework Core 4 and informative security references cited in the 
Cybersecurity Framework Core. 


1.1 The Challenge 

Both private industry and the government are concerned about email security and the use of 
email as an attack vector for cybercrime. Business operations are heavily reliant on email 
exchanges and need to protect the confidentiality of business information, the integrity of 
transactions, and privacy of individuals. Cryptographic services are used to authenticate the 
source of email messages, protect against undetected unauthorized alteration of messages in 
transit, and maintain message confidentiality. Efficiency and policies support reliance on mail 
servers to provide cryptographic protection for email rather than on end-to-end security 
operated by individual users. Flowever, organizations need to protect their server-based email 
security mechanisms against intrusion and man-in-the-middle attacks during automated 
cryptographic service negotiation. In the absence of an appropriate combination of DNSSEC 
and certificate-based protections, any of these attacks can result in disclosure or modification 
of information by unauthorized third parties. The attacks can also enable an attacker to pose as 
one of the parties to an email exchange and send email that contains links to malware-ridden 
websites. If other content in a fraudulent message successfully motivates the user to click on 
the link or the user's system is configured to automatically follow some links or download 
content other than text, the malware will infect the user's system. Inclusion of links to malware 
is a major factor in most confirmed data breaches. Consequences of such breaches can range 
from exposure of sensitive or private information, to enabling fraudulent activity by the 
attacker posing as the victimized user, to disabling or destroying the user's system-or that of the 
user's parent organization. Beyond avoidance of negative consequences to users, improved 
email security can also serve as a marketing discriminator for email service providers. 

Implementation of DNSSEC and DNS-Based Authentication Of Named Entities (DANE) 5 have 
been impeded in the past by a shortage of easily used software libraries and by the fact that 
most available email applications of the protocols respond to absent or incorrect digital 
signatures by neither permitting delivery of the message nor alerting the mail server that 
failure to deliver is based on a DNSSEC issue. The consequence of the first impediment is that, 
unless forced by policy to do so, IT organizations defer DNSSEC/DANE implementation pending 
availability of more mature software libraries. The consequence if the second is that, when 
DNSSEC and DANE are turned on, mail servers experience severe service degradation or crashes 
due to large numbers of retransmission attempts. 


4. http://www.nist.gov/cyberframework/ 

5. RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security 
Protocol: TLSA 
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1.2 The Solution 

DNSSEC protects against unauthorized modifications to domain name information to prevent 
connection to spoofed or malicious hosts. The NCCoE initiated a collaborative project with 
industry partners to develop a proof-of-concept security platform that provides trustworthy 
mail server-to-mail server email exchanges across organizational boundaries. Products 
comprising the security platform include client mail user agents (MUAs) 6 , DNS servers 
(authoritative and caching/recursive) 7 , mail transfer agents, (MTAs) 8 , and X.509 cryptographic 
key certificate sources (components and services). The network infrastructure products are 
similar to those found in every enterprise and used to perform basic IT functions and handle 
email. The certificate utilities are needed to produce X.509 certificates 9 for mail servers and 
end users to support Transport Layer Security (TLS) 10 and Secure/Multipurpose Internet Mail 
Extensions (S/MIME) 11 . This initial project focuses on Simple Mail Transfer Protocol (SMTP) 12 
over TLS and S/MIME. 

The DNS-based secure email building block project has demonstrated a security platform, 
consistent with SP 800-177, that provides trustworthy email exchanges across organizational 
boundaries. The project includes authentication of mail servers, digitally signing and encrypting 
email 13 , and binding cryptographic key certificates to the servers. The software library issue 
was addressed in SP 1800-6c by providing installation and configuration instructions for using 
and maintaining existing software libraries (including installation support applications). At the 
same time, inclusion of software developers and vendors in the development and 
demonstration process revealed software and implementation guidance shortcomings that 
have been corrected. 


6. According to NIST Special Publication (SP) 800-177, an MUA is a software component (or web 
interface) that allows an end user to compose and send messages and to one or more recipients. 
An MUA transmits new messages to a server for further processing (either final delivery or trans¬ 
fer to another server). 

7. According to Section 3.2 of SP 800-177, there are two main types of name servers: authorita¬ 
tive name servers and caching name servers. The term authoritative is with respect to a zone. If 
a name server is an authoritative source for DNS resource records for a particular zone (or zones) 
of DNS addresses, it is called an authoritative name server for that zone (or zones). An authori¬ 
tative name server for a zone provides responses to name resolution queries for resources for 
that zone, using the records in its own zone file. A caching name server (also called a resolv¬ 
ing/recursive name server), by contrast, provides responses either through a series of queries to 
authoritative name servers in the hierarchy of domains found in the name resolution query or 
from a cache of responses built by using previous queries. 

8. Also according to SP 800-177, mail is transmitted, in a "store and forward" fashion, across net¬ 
works via Mail Transfer Agents (MTAs). MTAs communicate using the Simple Mail Transfer Pro¬ 
tocol (SMTP) described below and act as both client and server, depending on the situation. 

9. RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List 
(CRL) Profile 

10. RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2 

11. RFC 5751, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message 
Specification 

12. RFC 5321, Simple Mail Transfer Protocol 

13. Cryptographic protection, while voluntary for the private sector has, for a number of appli¬ 
cations been made mandatory for federal government agencies (see Managing Information as a 
Strategic Resource, OMB Circular A-130) 
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, os 1.3 Benefits 


Sectors across industries, as well as the federal government, are concerned about email 
security and the use of email as an attack vector. 14 Both public and private sector business 
operations are heavily reliant on email exchanges. The need to protect the integrity of 
transactions containing financial and other proprietary information and to protect the privacy 
of employees and clients are among the factors that motivate organizations to secure their 
email. Whether the service desired is authentication of the source of an email message, 
assurance that the message has not been altered by an unauthorized party, or message 
confidentiality, cryptographic functions are usually employed. Economies of scale and a need 
for uniform implementation drive most enterprises to rely on mail servers to provide security to 
the members of an enterprise rather than security implemented and operated by individual 
users. Many server-based email security mechanisms are vulnerable to attacks involving: 

■ faked or fraudulent digital certificates 

■ otherwise invalid certificates 

■ failure to actually invoke a security process as a result of connection to or through a 
fraudulent server 


Even if there are protections in place, some attacks have been able to subvert email 
communication by attacking the underlying support protocols such as DNS. Attackers can spoof 
DNS responses to redirect email servers and alter email delivery. DNSSEC was developed to 
prevent this. DNSSEC protects against unauthorized modifications to network management 
information and host IP addresses. DNSSEC can also be used to provide an alternative 
publication and trust infrastructure for service certificates using the DNS-based Authentication 
of Named Entities (DANE) resource records. 


The business value of the security platform that results from this project includes improved 
privacy and security protections for users' communication, as well as improved management of 
DNS and email security operations. Addressing the software library and message 
retransmission issues, respectively, reduces the difficulty and cost of installing and maintaining 
DNSSEC and DANE. Mitigating the major cause of system errors resulting from faulty 
deployment of DNSSEC and DANE will encourage use of capabilities already present in many 
email systems. Demonstration and publication of these improvements encourages wider 
implementation of the protocols that provide Internet users with confidence that email has 
been protected and reaches the intended receiver in a secure manner. The demonstrated 
platform addresses three of the five core Functional Categories in the Framework for Improving 
Critical Infrastructure Cybersecurity and many requirements of relevant security standards and 
guidelines. Implementation of the platform will be increasingly important as a market 
discriminator as public awareness of email security and privacy issues grows. 


14. "How Cybercrime Exploits Digital Certificates," Infosec Institute, General Security, July 28, 
2014, http://resources.infosecinstitute.com/cybercrime-exploits-digital-certificates 
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1.4 Technology Partners and Collaborators 

The technology vendors who participated in this build submitted their capabilities in response 
to a notice in the Federal Register. Companies with relevant products were invited to sign a 
Cooperative Research and Development Agreement (CRADA) with NIST, allowing them to 
participate in a consortium to build this example solution. We worked with: 

■ Microsoft Corporation 

■ NLnet Laboratories 

■ Secure64 

■ Internet Systems Consortium 

■ Fraunhofer IAO 

1.5 Feedback 

You can improve this guide by contributing feedback. As you review and adopt this solution for 
your own organization, we ask you and your colleagues to share your experience and advice 
with us. 

■ email dns-email-nccoe@nist.gov 

■ join our Community of Interest to offer your insights and expertise; email us at 

dns-email-nccoe@nist.gov 

Or learn more by arranging a demonstration of this example solution by contacting us at 

dns-email-nccoe@nist.gov 
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2 How to Use This Guide 


This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design and 
provides users with the information they need to replicate this approach to email security. The 
reference design is modular and can be deployed in whole or in parts. 

This guide contains three volumes: 

■ NIST SP 1800-6a: Executive Summary 

■ NIST SP 1800-6b: Approach, Architecture, and Security Characteristics - what we built and 
why (you are here) 

■ NIST SP 1800-6c: How-To Guides - instructions for building the example solution 

Depending on your role in your organization, you might use this guide in different ways: 

Business decision makers, including chief security and technology officers will be interested in 
the Executive Summary (NIST SP 1800-6a), which describes the: 

■ challenges enterprises face in implementing and operating a trustworthy email service 

■ example solution built at the NCCoE 

■ benefits of adopting the example solution 

Technology or security program managers who are concerned with how to identify, 
understand, assess, and mitigate risk will be interested in this part of the guide. NIST SP 1800- 
6b describes what we did and why. Section 4.4, Risk Assessment will be of particular interest. 
This section provides a description of the risk analysis we performed and maps the security 
services provided by this example solution to the Framework for Improving Critical 
Infrastructure Cybersecurity and relevant security standards and guidelines. 

You might share the Executive Summary, NIST SP 1800-6a, with your leadership team members 
to help them understand the importance of adopting standards-based access management 
approaches to protect your organization's digital assets. 

IT professionals who want to implement an approach like this will find the whole practice guide 
useful. You can use the How-To Guides, NIST SP 1800-6c, to replicate all or parts of the build 
created in our lab. The How-To guide provides specific product installation, configuration, and 
integration instructions for implementing the example solution. We do not re-create the 
product manufacturers' documentation, which is generally widely available. Rather, we show 
how we incorporated the products together in our environment to create an example solution. 

This guide assumes that IT professionals have experience implementing security products 
within enterprises. While we have used a suite of commercial and open source software 
products to address this challenge, this guide does not endorse these particular products. Your 
organization can adopt this solution or one that adheres to these guidelines in whole, or you 
can use this guide as a starting point for tailoring and implementing parts of a solution that 
would support the deployment of an trustworthy email system and the corresponding business 
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processes. Your organization's security experts should identify the products that will best 
integrate with your existing tools and IT system infrastructure. We hope you will seek products 
that are congruent with applicable standards and best practices. Section 4.5, Technologies, lists 
the products we used and maps them to the cybersecurity controls provided by this reference 
solution. 

A NIST Cybersecurity Practice Guide does not describe "the" solution, but a possible solution. 
This is a draft guide. We seek feedback on its contents and welcome your input. Comments, 
suggestions, and success stories will improve subsequent versions of this guide. Please 
contribute your thoughts to dns-email-nccoe(5)nist.gov. 
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3 Introduction 


As stated in section 1.1, both public and private sector business operations are heavily reliant 
on electronic mail (email) exchanges. They need to protect the integrity of transactions that 
may include financial and other proprietary information. The privacy of employees and clients 
is also a factor that motivates organizations to secure their email systems. Security services 
such as the authentication of the source of an email message, assurance that the message has 
not been altered by an unauthorized party, and confidentiality of message contents require the 
use of cryptographic functions. A need for uniform security implementation drives most 
enterprises to rely on mail servers to provide security to the members of an enterprise rather 
than rely on end users to implement a security policy on their own. However, most current 
server-based email security mechanisms are vulnerable to, and have been defeated by, attacks 
on the integrity of the cryptographic implementations on which they depend. The 
consequences frequently involve unauthorized parties being able to read or modify supposedly 
secure information, or to use email as a vector for inserting malware into the enterprise. 
Improved email security can help protect organizations and individuals against these 
consequences and also serve as a marketing discriminator for email service providers as well as 
improve the trustworthiness of enterprise email exchanges. 

Domain Name System Security Extensions for the Domain Name System are technical 
mechanisms employed by domain owners to protect against unauthorized modification to 
network management information. DANE is a protocol that securely associates domain names 
with cryptographic certificates and related security information so that clients can better 
authenticate network services. In spite of the dangers of failure to authenticate the identities of 
network devices, adoption of DNSSEC has been slow. Demonstration of DANE-supported 
applications such as reliably secure email may support increased user demand for domain 
name system security. Follow-on projects might include HTTPS, IOT, IPSEC keys in DNS, and DNS 
service discovery. 

The DNS-Based Email Security project demonstrated proof of concept security platforms 
composed of off the shelf components that provides trustworthy mail server-to-mail server 
email exchanges across organizational boundaries. The DANE protocol is used to authenticate 
servers and certificates in two roles in the DNS-Based Security for Email Project: (1) By binding 
the X.509 certificates used for Transport Layer Security (TLS) to DNSSEC signed names for mail 
server-to-mail server communication; and (2) by binding the X.509 certificates used for 
Secure/Multipurpose Internet Mail Extensions (S/MIME) to email addresses encoded as DNS 
names. These bindings support trust in the use of S/MIME certificates in the end-to-end email 
communication. The resulting platforms encrypt email traffic between servers and allow 
individual email users to obtain other users' certificates in order to validate signed email or 
send encrypted email. 1 The project will include an email sending policy consistent with a stated 
privacy policy that can be parsed by receiving servers so that receiving servers can apply the 
correct security checks. 


1. S/MIME can do this now, but DANE makes it easier to actually use. 
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Documentation of the resulting platform includes statements of the security and privacy 
policies and standards (e.g., Executive Orders, NIST standards and guidelines, IETF RFCs). This 
also includes technical specifications for hardware and software, implementation 
requirements, and a mapping of implementation requirements to the applicable policies, 
standards, and best practices. 

The secure email project has involved composition of a variety of components that were 
provided by several different technology providers. Components include MUAs, DNSSEC 
capable DNS servers, MTAs, and cryptographic certificate sources. These components are used 
to generate and host DNSSEC signed zones and TLS enabled mail services. 

This project resulted in demonstration of support to MUAs and MTAs by four DNS-based secure 
email platforms and this publicly available NIST Cybersecurity Practice Guide that explains how 
to employ the suite(s) to meet security and privacy requirements. This guide also provides 
platform documentation necessary to compose a DNS-based email security platform from off 
the shelf components that composed the prototype platforms. 
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4.1 Audience 

This guide is intended for individuals responsible for implementing security solutions in 
organizations' IT support activities. Current IT systems, particularly in the private sector often 
lack integrity protection for domain name services and electronic mail. The platforms 
demonstrated by the DNS-Based Email Security project, and the implementation information 
provided in these Practice Guides permit integration of DNS and email integrity services and 
email confidentiality services with minimum changes to existing infrastructure or impact to 
service operations. The technical components will appeal to system administrators, IT 
managers, IT security managers, and others directly involved in the secure and safe operation 
of the business IT networks. 


4.2 DNS-Based Electronic Mail Security Project Scope 

The DNS-Based Electronic Mail Security project is consistent with NIST SP 800-177 and 
demonstrates the use of off-the-shelf Transport Layer Security (TLS), Domain Name System 
(DNS) Security Extensions (DNSSEC), and DNS-based Authentication of Named Entities (DANE) 
components to achieve trustworthy electronic mail (email) objectives in a manner that is 
consistent with NIST SP 800-81-2. 

4.2.1 Transport Layer Security (TLS) 

The project uses TLS to protect confidentiality of email messages exchanged between mail 
servers. TLS relies on keys stored as X.509 digital certificates. These certificates can be used to 
authenticate the identity (server, domain or organization) of the certificate owner. 

4.2.2 Domain Name System (DNS) Security Extensions (DNSSEC) 

The project uses DNSSEC to authenticate and protect the integrity of DNS data. DNSSEC uses 
digital signatures over DNS data to prevent an attacker from tampering with or spoofing DNS 
responses. Mail servers use the DNS to find the destination of email as well as storing other 
artifacts necessary for email security (see below). 

4.2.3 DNS-based Authentication of Named Entities (DANE) 

The project uses DANE, a protocol that securely associates domain names with cryptographic 
certificates and related security information so that they can't be fraudulently modified or 
replaced to breach security. DNSSEC binds the X.509 certificates used for TLS to DNS. 

4.2.4 Binding X.509 Certificates with DANE 

The project also uses DANE to bind the X.509 certificates used for S/MIME to email addresses 
encoded as DNS names verified by DNSSEC. 
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4.2.5 Demonstration of Digital Signature and Encryption of Email 

The project demonstrates sending encrypted messages between email systems resident in 
different DNS domains, where the email exchanges between two organizations' email servers 
are carried over TLS, and the TLS key management is protected by DANE and DNSSEC. Signed 
email was sent between a message originator and a receiving party using end user applications 
(end-to-end) in different DNS domains, where the email exchanges between organizations 
were carried over TLS, the email messages were signed and verified with S/MIME on the 
end-users' client devices, and the S/MIME key management was protected by DANE and 
DNSSEC. In addition, the project demonstrated that the use of DNSSEC and DANE blocks an 
attempt by a fraudulent mail server to pose as the legitimate mail server for the receiver of the 
email. 


4.2.6 Demonstration of End-to-end Digital Signature of Mail 

The project's digital signature demonstration included sending S/MIME signed email between a 
message originator and a receiving party using end user applications in different DNS domains. 
The email exchanges between organizations are carried over TLS, the email messages are 
signed and verified with S/MIME on the end-users' client devices, and the S/MIME certificates 
are stored in the DNS and protected by DNSSEC. This aspect of the project also demonstrated 
that use of DANE blocks an attempt by a fraudulent actor to pose as the email originators. 


4.3 Assumptions 

4.3.1 Security and Performance 

The email platforms and DNS services demonstrated provide email integrity and confidentiality 
protection. An underlying assumption is that the benefits of using the demonstrated platforms 
outweigh any additional performance risks that may be introduced. The security of existing 
systems and networks is out of scope for this project. A key assumption is that all potential 
adopters of one of the demonstrated builds, or any of their components, already have in place 
some degree of network security. Therefore, we focused on what potential new system 
vulnerabilities were being introduced to end users if they implement this solution. The goal of 
this solution is to not introduce additional vulnerabilities into existing systems, but there is 
always inherent risk when adding systems and adding new features into an existing system. 

4.3.2 Modularity 

This assumption is based on one of the NCCoE core operating tenets. It is reasonably assumed 
that organizations already have mail client and server systems in place. Our philosophy is that a 
combination of certain components or a single component can improve email security for an 
organization; they may not need to remove or replace most existing infrastructure. This guide 
provides a complete top-to-bottom solution and is also intended to provide various options 
based on need. 
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4.3.3 Technical Implementation 

This practice guide is written from a "how-to" perspective, and its foremost purpose is to 
provide details on how to install, configure, and integrate the components. The NCCoE assumes 
that an organization has the technical resources to implement all or parts of the build, or has 
access to companies that can perform the implementation on its behalf. 

4.3.4 Operating System and Virtual Machine Environments 

This project was conducted primarily in a Vmware vcenter server version 6.0.0 Build 3018523 
virtual machine environment. It is assumed that user organizations will be able to install the 
demonstrated applications in cloud-hosted VMs, local virtual machine or local native server 
client environments. This project uses Centos 7, Windows Server 2012R2, and Windows 10 
operating systems. Operating systems were chosen based on the requirements of the software. 

The DNS-based secure email building block project assumes, and is dependent upon, the 
availability of off-the shelf information security technology. Particular products and expertise 
on which the project is dependent include those for MUAs, MTAs, DNS servers (authoritative 
and recursive) and X.509 certificate utilities. 


4.4 Risk Assessment 

According to NIST SP 800-30, Risk Management Guide for Information Technology Systems, 
"Risk is the net negative impact of the exercise of a vulnerability, considering both the 
probability and the impact of occurrence. Risk management is the process of identifying risk, 
assessing risk, and taking steps to reduce risk to an acceptable level." The NCCoE recommends 
that any discussion of risk management, particularly at the enterprise level, begin with a 
comprehensive review of NIST 800-37, Guide for Applying the Risk Management Framework to 
Federal Information Systems. The risk management framework (RMF) and its associated 
references for identified security functions provides a baseline for organizing and relating to 
organizational objectives of: 

1. the risks to electronic mail and the networks it transits 

2. the security requirements to be met in order for the security platform to reduce these risks 

While this guide does not present a full risk assessment, it does highlight the broad categories 
of threats and vulnerabilities associated with electronic mail. 


4.4.1 Threats 

Below are common threats associated with electronic mail: 

■ use of email as a vehicle for introducing malware 

■ use of email as a delivery mechanism for social engineering attacks 

■ theft or destruction of data communicated by email and/or its attachments due to loss or 
unauthorized/unintentional disposal of messages 

■ loss of privacy resulting from unauthorized access to email 
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■ unauthorized modification of information communicated by email 

■ malicious fraudulent creation of messages or attachments attributed to third parties 


, A.4.2 Vulnerabilities 

is Vulnerabilities are commonly associated with mail client applications, mail transfer 

is applications, and network applications that are employed in creation, delivery, and reading of 

I? email. However, vulnerabilities can be exploited at all levels in the information stack. For 

is up-to-date information regarding vulnerabilities, this guide recommends that security 

1 9 professionals leverage the National Vulnerability Database (NVD). The NVD is the U.S. 

20 government repository of standards-based vulnerability management data 

21 [https://nvd.nist.gov], 

22 4.4.2.1 Client System Vulnerabilities 

23 Organizations are getting better at protecting network perimeters, and companies with mature 

24 security programs usually allow only certain ports through the firewall and harden 

25 Internet-accessible servers to minimize the attack surface. As a result, attackers are paying 

26 closer attention to client-side vulnerabilities on internal workstations. These client-side 

27 vulnerabilities often are as simple as unpatched software on a desktop or laptop. Most client 

28 systems run at least one operating system and quite a few applications. Listing specific 

29 vulnerabilities for each is beyond the scope of this guide, but a current list of vulnerabilities and 

30 information regarding patches are available from NIST's National Vulnerability Database 

31 referenced above. Depending on the nature of a vulnerable application, an attacker may exploit 

32 it using a specially crafted email attachment or by convincing the user to visit a malicious Web 

33 site. Web browsers are common targets. Other attractive targets include Adobe Acrobat 1 , 

34 Macromedia Flash 2 , QuickTime 3 and Java Runtime Environment 4 . 


35 4.4.2.2 Mail Server Vulnerabilities 

36 Mail servers have many of the same vulnerabilities as client systems, but we also need to be 

s? aware of protocol-based vulnerabilities involving access to valid lists of email addresses, 

38 vulnerabilities to relay exploits for malware insertion, vulnerabilities to email header 

39 disclosures, and vulnerabilities to viruses and worms. In the case of SMTP, one way that 

40 attackers can verify whether e-mail accounts exist on a server is simply to telnet to the server 

4 1 on port 25 and run the VRFY command . 5 The VRFY command makes a server check whether a 

42 specific user ID exists. Spammers often automate this method to perform a directory harvest 

43 attack, which is a way of gleaning valid e-mail addresses from a server or domain for hackers to 


1. See https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-497/Adobe-Ac- 
robat-Reader.html. 

2.See 

https://www.cvedetails.com/vulnerability-list/vendor_id-73/product_id-1950/version_id-8545 
/Macromedia-Flash-Player-6.0.29.0.html. 

3. See https://web.nvd.nist.gov/view/vuln/detail?vulnld=CVE-2015-7117. 

4. See https://web.nvd.nist.gov/view/vuln/detail?vulnld=CVE-2015-4903. 

5. A number of ISPs now block port 25. 
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use. Scripting this attack can test thousands of e-mail address combinations. The SMTP 
command EXPN may allow attackers to verify what mailing lists exist on a server. Yet another 
way to capture valid e-mail addresses is to use applications such as theHarvester to glean 
addresses via Google and other search engines. In Microsoft Exchange, account enumeration is 
not generally an issue. 

In environments other than Microsoft Exchange, account enumeration is not generally an issue. 
In such environments, the best solution for preventing this type of e-mail account enumeration 
depends on whether you need to enable commands like SMTP's VRFY and EXPN commands. In 
general, it is important to ensure that company e-mail addresses are not posted on the web. 

Protocols like SMTP relay let users send e-mails through external servers. Open e-mail relays 
aren't the problem they used to be, but they can still be sources of vulnerabilities. Spammers 
and hackers can use an e-mail server to send spam or malware through e-mail under the guise 
of the unsuspecting open-relay owner. 

In the case of email header disclosures, e-mail servers configured with typical defaults, may be 
vulnerable to divulging information such as internal IP addresses of e-mail clients, software 
versions of client and e-mail servers along with their vulnerabilities, or host names that can 
divulge network naming conventions 

Email systems are regularly targeted by malware such as viruses and worms. It is necessary to 
verify that mail servers' antivirus software is actually working. As in the case of client systems 
vulnerabilities, NIST's National Vulnerability Database (https://nvd.nist.gov) is a frequently 
updated source of vulnerabilities that affect mail servers. 


,65 4.4.2.3 Network Vulnerabilities 

,66 The MITRE Corporation's Common Vulnerability Enumeration (CVE) lists more than 85,000 

,67 vulnerabilities that can affect web servers, System Query Language (SQL) servers, DNS servers, 

, 6 e firewalls, routers, and other network components (see https://cve.mitre.org). These include 

,69 vulnerabilities to denial of service, code execution, overflow, cross-site scripting, directory 

, 7 o traversal, process bypass, unauthorized gaining of information, SQL injection, file inclusion, 

,7, memory corruption, cross-site request forgery, and http response splitting. Many of the 

,72 vulnerabilities are operating system or applications-based. Others are protocol based (e.g. 

,73 vulnerabilities inherent in IP 6 , TLS, DNS 7 , BGP 8 , SMTP and other network protocols). As in the 

,74 case of client systems vulnerabilities, NIST's National Vulnerability Database 

,75 (https://nvd.nist.gov) is a frequently updated source of vulnerabilities that affect network 

,76 servers. 


4.4.3 Risk 

Risks are examined from the point of view of consequences of vulnerabilities being exploited. 
Some examples of these consequences include legal liability, consequences of failure to comply 
with regulations, confidentiality breaches, loss of productivity, and damage to organizational 
reputation. 


6. RFC 791, Internet Protocol 

7. RFC 1034, Domain Names - Concepts And Facilities 

8. RFC 4271, A Border Gateway Protocol 4 (BGP-4) 
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■ New and existing regulations are force organizations to keep a record of their emails and to 
protect their employee and customer privacy. For example, the Health Insurance Portability 
and Accountability Act (HIPAA) requires health care institutions to keep a record of their 
email communications and secure confidentiality of information. In the new IRS regulation 
Circular 230, the IRS requires tax advisors to add an email disclaimer to any emails including 
tax advice, expressly stating that the opinion cannot be relied upon for penalty purposes. 
The U.S. Securities and Exchange Commission and Gramm-Leach-Bliley Act impose similar 
duties on financial institutions. Steep penalties can apply to those organizations that do not 
comply with their industry's regulations. In a case lasting from 2000 until 2005, a 
well-known financial institution was recently forced to pay 20 million dollars in penalties by 
the Securities and Exchange Commission for not diligently searching for email back-up 
tapes and over-writing multiple back-up tapes. 

■ Most confidentiality breaches occur from within the company. These breaches can be 
accidental, but they can also be intentional. 


■ With respect to legal liability, organizations are generally held responsible for all the 
information transmitted on or from their system, so inappropriate emails sent on the 
company network can result in multi-million dollar penalties. 


■ Employees sending personal emails and sifting through spam mail can cause major loss of 
productivity. 9 


■ Even just a badly written email, or an email containing unprofessional remarks will cause 
the recipient to gain a bad impression of the company that the sender is representing. 
Fraudulent email attributable to an organization can do far more damage to an 
organization's reputation, both in terms of the response elicited and in terms of loss of 
confidence in the cybersecurity reliability of the organization 


A number of cybersecurity actions are recommended to reduce these risks. The Framework 
Core identified in NIST's Framework for Improving Critical Infrastructure Cybersecurity is a set of 
cybersecurity activities, desired outcomes, and applicable references that are common across 
critical infrastructure sectors. The Core presents industry standards, guidelines, and practices in 
a manner that allows for communication of cybersecurity activities and outcomes across the 
organization from the executive level to the implementation/operations level. The Framework 
Core consists of five concurrent and continuous Functions: Identify, Protect, Detect, Respond, 
and Recover. When considered together, these functions provide a high-level, strategic view of 
the lifecycle of an organization's management of cybersecurity risk. 


9. Current SPAM filtering solutions consist of some sort of filtering at the network or the PC level, 
and they don't reveal the details of the sender without looking up the source. It takes some work 
for the recipient. This will always put us one step behind the bad guys. DNS provides the neces¬ 
sary Internet-wide scaling and DNSSEC achieves this authentication. 
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4.4.4 Cybersecurity Framework Functions, Categories, and Subcategories 
Addressed by the DNS-Based Email Security Project 

The Framework for Improving Critical Infrastructure Cybersecurity 10 (Cybersecurity Framework) 
provides a common language for understanding, managing, and expressing cybersecurity risk 
both internally and externally. It can be used to help identify and prioritize actions for reducing 
cybersecurity risk, and it is a tool for aligning policy, business, and technological approaches to 
managing that risk. It can be used to manage cybersecurity risk across entire organizations or it 
can be focused on the delivery of critical services within an organization. Different types of 
entities - including sector coordinating structures, associations, and organizations - can use the 
Cybersecurity Framework for different purposes, including the creation of common Profiles. As 
stated above, the Framework Core provides a set of activities to achieve specific cybersecurity 
outcomes, and references examples of guidance to achieve those outcomes. The Core is not a 
checklist of actions to perform. It presents key cybersecurity outcomes identified by industry as 
helpful in managing cybersecurity risk. The Core comprises four elements: Functions, 
Categories, Subcategories, and Informative References. 

■ Functions organize basic cybersecurity activities at their highest level. These Functions are 
Identify, Protect, Detect, Respond, and Recover. They aid an organization in expressing its 
management of cybersecurity risk by organizing information, enabling risk management 
decisions, addressing threats, and improving by learning from previous activities. The 
Functions also align with existing methodologies for incident management and help show 
the impact of investments in cybersecurity. For example, investments in planning and 
exercises support timely response and recovery actions, resulting in reduced impact to the 
delivery of services. 

■ Categories are the subdivisions of a Function into groups of cybersecurity outcomes closely 
tied to programmatic needs and particular activities. Examples of Categories include "Asset 
Management," "Access Control," and "Detection Processes." 

■ Subcategories further divide a Category into specific outcomes of technical and/or 
management activities. They provide a set of results that, while not exhaustive, help 
support achievement of the outcomes in each Category. Examples of Subcategories include 
"External information systems are cataloged," "Data-at-rest is protected," and 
"Notifications from detection systems are investigated." 

■ Informative References are specific sections of standards, guidelines, and practices 
common among critical infrastructure sectors that illustrate a method to achieve the 
outcomes associated with each Subcategory. The Informative References presented in the 
Framework Core are illustrative and not exhaustive. They are based upon cross-sector 
guidance most frequently referenced during the Framework development process. 

The DNS-Based E-Mail Security Building Block project supports the Cybersecurity Framework's 
Protect, Detect, and Respond Functions. Applicability to specific categories, subcategories, and 
functions is described in the following paragraphs. 


10. Framework for Improving Critical Infrastructure Cybersecurity, Version 1.0, National Institute 
of Standards and Technology February 12, 2014. http://www.nist.gov/cyberframework/up- 
load/cybersecurity-framework-021214.pdf 
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254 4.4.4.1 Protect 

255 The Protect function develops and implements the appropriate safeguards needed to ensure 

256 delivery of critical infrastructure services. This function supports the ability to limit or contain 

257 the impact of a potential cybersecurity event. Examples of outcome Categories within this 

258 Function that are addressed by the DNS-Based E-Mail Security project include: Access Control 

259 and Protective Technology. 

260 1. Access Control (PR.AC) 

26 1 The Protect Function's Access Control Category supports an outcome in which access to 

262 assets and associated facilities is limited to authorized users, processes, or devices, and to 

263 authorized activities and transactions. 

264 a. PR.AC-1 


The PR.AC-1 subcategory under Access Control supports identities and credentials 
being managed for authorized devices and users. The security platform resulting from 
the DNS-Based E-Mail Security project supports effective management of the 
credentials associated with the addresses from which electronic mail purportedly 
originates and the integrity of the user identities associated with the electronic mail. 


The original design of the Domain Name System (DNS) did not include security; instead, 
it was designed to be a scalable distributed system. DNSSEC and DANE attempt to add 
security, while maintaining backward compatibility with the existing DNS. DNSSEC was 
designed to protect applications (and caching resolvers serving those applications) from 
using forged or manipulated DNS data. All answers from DNSSEC protected zones are 
cryptographically signed (i.e., digital signature over DNS data). By checking the digital 
signature, a DNS resolver is able to determine whether the information is authentic (i.e. 
unmodified and complete) and is served on an authoritative DNS server. While 
protecting IP addresses is the immediate concern for many users, DNSSEC can protect 
any data published in the DNS, including text records or mail exchange (MX) records, 
and can be used to bootstrap other security systems that publish references to 
cryptographic certificates stored in the DNS. 


All DNSSEC responses contain signed DNS data. DNSSEC signature validation allows the 
use of potentially untrustworthy parties if (for example) the mail server is using a 
self-signed certificate. The protocol permit configuration of systems to accept messages 
whether or not they are digitally signed. The security platform developed under the 
DNS-Based E-Mail Security project permits electronic mail clients and transfer agents to 
be configured systems to send email messages to only server whose DNS entries are 
digitally signed. At the client systems level (e.g., Outlook, Postfix, Thunderbird), digital 
signature of the mail messages themselves can also be applied on user-to-user basis. In 
the user-to-user case, the signature provides assurance of the integrity of the identity of 
the sender rather than just the identity of the DNS zone(s) associated with the sender. 


b. PR.AC-3 


The PR.AC-3 subcategory under Access Control supports management of remote 
access. One of the most common vectors for malware infection is a user clicking on a 
link that is included in an e-mail message from a spoofed source. Clicking on the link 
enables remote access to the user's system, and preventing delivery of e-mail from 
bogus sources represents a management control protecting against remote access by 
malicious entities. The DNS-Based E-Mail Security project's demonstrated security 
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platform can be used as a basis for accepting or refusing electronic mail based on 
authenticated data stored in the DNS. This has an added benefit of supporting 
protection against remote access based on other than e-mail functions. 

c. PR.AC-5 


The PR.AC-5 subcategory under Access Control supports protection of network integrity 
by incorporating network segregation where appropriate. The DNS-Based E-Mail 
Security project does not employ specifically network segregation principles. However, 
it does support network integrity by providing operationally feasible mechanisms for 
preventing connections or message delivery to sources that do not implement a 
specified set of DNS security extensions. Rigorous adherence to a minimum security 
configuration can enforce effective isolation of a network from entities that do not 
conform to the network's security requirements. 

2. Data Security (PR.DS) 


312 The Protect Function's Data Security Category supports an outcome in which information 

3 1 3 and records (data) are managed consistent with the organization's risk strategy to protect 

314 the confidentiality, integrity, and availability of information. The DNS-Based E-Mail Security 

sis project demonstrates a capability to provide source and content integrity protection by 

3 i 6 employing digital signature of messages and confidentiality protection by encrypting 

si? messages. 


a. PR.DS-1 

The PR.DS-1 subcategory under Data Security supports protection of data at rest. The 
user-to-user digital signature capability demonstrated by the DNS-Based E-Mail Security 
project can provide an ability to verify the source and content integrity of stored e-mail 
messages where the digital signature is stored with the rest of the message. This 
supports integrity protection for data-at-rest. 

b. PR.DS-2 

The PR.DS-2 subcategory under Data Security supports protection of data in transit. In 
addition to user-to-user digital signature of e-mail, the DNS-Based E-Mail Security 
project demonstrates a capability to provide source and content integrity protection to 
data-in-transit by employing server-to-server confidentiality protection to 
data-in-transit by employing server-to-server encryption. 

c. PR.DS-6 


The PR.DS-6 subcategory under Data Security supports use of integrity checking 
mechanisms to verify software, firmware, and information integrity. The digital 
signature of e-mail demonstrated by the DNS-Based E-Mail Security project's security 
platform supports automatic integrity checking of information communicated in e-mail 
messages. DNSSEC and DANE protect the integrity of address information. 


3. Protective Technology (PR.PT) 


The Protect Function's Protective Technology Category's goal is to ensure the security and 
resilience of systems and assets by managing a technical security solution consistent with 
related policies, procedures, and agreements. 
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a. PR-PT-4 

The PR.PT-4 subcategory under Protective Technology supports protection of 
communications and control networks. The DNS-Based E-Mail Security project 
demonstrates a capability to provide source and content integrity protection by 
employing digital signature of communications and confidentiality protection by 
encrypting communications. The support demonstrated for use of DNSSEC and DANE 
protocols also support communications and control network integrity by demonstrating 
operationally feasible mechanisms for refusing connections to or message delivery from 
sources that do not implement a specified set of DNS security extensions. Rigorous 
adherence to a minimum security configuration can be use to enforce isolation 
networks from entities that do not conform to the network's security requirements. 


35 ,4.4.4.2 Detect 


The Detect Function develops and implements the appropriate activities needed to identify in a 
timely manner the occurrence of a cybersecurity event. Examples of outcome categories within 
this function that are addressed by the DNS-Based E-Mail Security project include Security 
Continuous Monitoring and Detection Processes. 


1. Security Continuous Monitoring (DE.CM) 

The Security Continuous Monitoring Category supports an outcome in which information 
system and assets are monitored at discrete intervals to identify cybersecurity events and 
to verify the effectiveness of protective measures. While not a classic example of 
continuous monitoring, the DNS-Based E-Mail Security platform has the ability to 
automatically check all DNS responses for correct digital signatures. 


a. DE.CM-1 

The DE.CM-1 subcategory under Security Continuous Monitoring supports monitoring 
of networks to detect potential cybersecurity events. While not a classic example of 
continuous monitoring, the demonstrated capability of the DNS-Based E-Mail Security 
platform to automatically check all inbound DNS responses for valid digital signatures 
permits identification of attempts to spoof systems using bogus DNS data. Automatic 
signing and signature validation for e-mail permits continuous checking for false sender 
identities and modification of message content. 

b. DE.CM-6 


The DE.CM-6 subcategory under Security Continuous Monitoring supports monitoring 
of external service provider activity to detect potential cybersecurity events. While not 
a classic example of continuous monitoring, the demonstrated capability of the 
DNS-Based E-Mail Security platform to automatically check all inbound DNS responses 
for valid digital permits detection and prevention of attempts by invalid service 
providers (e.g., bogus Certificate Authorities or Mail Transfer Agents) to spoof users' 
systems (including man-in-the-middle attacks). 


2. Detection Processes (DE.DP) 


The Detection Processes Category supports an outcome in which detection processes and 
procedures are maintained and tested to ensure timely and adequate awareness of 
anomalous events. 
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a. DE.DP-4 

The DE.DP-4 subcategory under Detection Processes supports event communication of 
detection information to appropriate parties. One of the shortcomings of most DNSSEC 
and DANE mechanisms is that they abort delivery of messages from sources whose 
DNSSEC signature checks fails to validate and do not provide any indication that failure 
is due to an invalid signature. This usually results in numerous retransmissions and 
consequent performance degradation or possible crashes. The DNS-Based E-Mail 
Security platform includes in its DNS resolvers notifications of DNS signature failures to 
mail agents in order to prevent consequent performance degradation. This 
communication of detection information has the potential to mitigate one of the 
primary impediments to private sector adoption of DNSSEC. 


393 4.4.4.3 Respond 

394 The Respond Function develops and implements the appropriate activities to take action 

395 regarding a detected cybersecurity event. This Function supports the ability to contain the 

396 impact of a potential cybersecurity event. Examples of outcome categories within this function 

397 that are addressed by the DNS-Based E-Mail Security project include: Response Planning, 

39 b Communications, and Mitigation. 

399 1. Response Planning (RS.RP) 

400 The Response Planning Category supports an outcome in which response processes and 

401 procedures are executed and maintained, to ensure timely response to detected 

402 cybersecurity events. 


a. RS.RP-1 

The RS.RP-1 subcategory under Response Planning supports execution of a response 
plan during or after an event. Inclusion of DNS and email security in security planning 
for systems connected to the Internet will necessarily include responses to detection of 
invalid digital signatures that include security flagging of connections and messages, 
and/or refusing connections and delivery of messages. Concurrent with detection of 
validation failure detection, these responses are demonstrated by the DNS-Based 
E-Mail Security platform. 


2. Communications (RS.CO) 

The RS.CO-2 subcategory under Communications supports reporting of events consistent 
with established criteria. As stated under DE.DP-4, one of the shortcomings of most DNSSEC 
and DANE mechanisms is that they abort delivery of messages to destinations whose 
DNSSEC signature checks fail but do not provide any indication that the failure is due to an 
invalid signature. In order to prevent consequent performance degradation, the DNS-Based 
E-Mail Security platform includes in its DNS resolver configuration notifications of DNSSEC 
signature failures to mail agents (i.e. configuration to log relevant DNSSEC issues). This 
communication of detection information has the potential to mitigate one of the primary 
impediments to private sector adoption of DNSSEC. It also provides a mechanism that can 
be exploited to provide to external stakeholders information involving failures of DNSSEC 
signature checks. 

a. RS.CO-2 

The RS.CO-2 subcategory under Communications supports reporting of events 
consistent with established criteria. As stated under DE.DP-4, one of the shortcomings 
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of most DNSSEC and DANE mechanisms is that they abort delivery of messages to 
destinations whose DNSSEC signature checks fail but do not provide any indication that 
the failure is due to an invalid signature. In order to prevent consequent performance 
degradation, the DNS-Based E-Mail Security platform includes in its DNS resolvers 
notifications of DNSSEC signature failures to mail agents. This communication of 
detection information has the potential to mitigate one of the primary impediments to 
private sector adoption of DNSSEC. It also provides a mechanism that can be exploited 
to provide to external stakeholders information involving failures of DNSSEC signature 
checks. 

3. Mitigation (RS.MI) 

a. RS.MI-1 

The RS.MI-1 subcategory under Mitigation supports containment of incidents. In the 
case of incidents that compromise the integrity of network systems through which 
electronic mail is routed, the effects of the compromise can be limited to those local 
systems and devices that have not implemented the integrity and confidentiality 
mechanisms demonstrated by the DNS-Based E-Mail Security platform. 11 

b. RS.MI-2 

The RS.MI-2 subcategory under Mitigation supports mitigation of incidents. The 
DNS-Based E-Mail Security project demonstrates user-to-user digital signature of 
messages. Retention of their digital signatures with stored messages permits later 
determination of whether the messages have been modified in storage. This can be a 
mitigating factor in the case of incidents that involve introduction of fraudulent 
information into electronic mail records. The project's demonstration of 
server-to-server encryption provides confidentiality protection for data-in-transit. This 
confidentiality protection can serve as a mitigating factor in the case of incidents 
involving unauthorized access to messages captured by network devices that sit 
between the sender's and recipient's mail servers. 


4.4.5 Cybersecurity References Directly Tied to those Cybersecurity 
Framework Categories and Subcategories Addressed by the 
DNS-Based Email Security Project 

The following security references were followed in accepting components for the DNS-Based 
Email Security platform, designing the platform, conducting demonstrations of the platform, 
and documenting the platform. The Framework functions, categories, and subcategories 
addressed by these references are listed for each reference. While many of the references were 
written as standards and guidelines to be applied to federal government agencies, their 
recommendations may also be applied in the private sector as best practices that support 
Cybersecurity Framework functional categories and subcategories. Those subcategories 
addressed by the DNS-Based Email Security platform are in boldface. 


11. Note that, if a system is subverted, a lot of assumed security goes out the window. A subvert¬ 
ed sending MTA could still be seen as valid by receivers for example. 
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1. Security Requirements for Cryptographic Modules, Federal Information Processing Standard 
(FIPS), FIPS 140-2, May 2001. http://csrc.nist.gov/publications/fips/fipsl40-2/fipsl402.pdf 

FIPS 140-2 provides a standard that is required to be used by Federal organizations when 
these organizations specify that cryptographic-based security systems be used to provide 
protection for sensitive or valuable data. Protection of a cryptographic module within a 
security system is necessary to maintain the confidentiality and integrity of the information 
protected by the module. All cryptographic components employed by the Federal 
government outside the national security community, including NCCoE security platforms 
that employ cryptography, must conform to FIPS 140-2. This standard specifies the security 
requirements that will be satisfied by a cryptographic module. The standard provides four 
increasing qualitative levels of security intended to cover a wide range of potential 
applications and environments. The security requirements cover areas related to the secure 
design and implementation of a cryptographic module. These areas include cryptographic 
module specification; cryptographic module ports and interfaces; roles, services, and 
authentication; finite state model; physical security; operational environment; 
cryptographic key management; electromagnetic interference/electromagnetic 
compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks. 

Within the context of the Cybersecurity Framework, FIPS 140-2 provides standards for 
"Protection" to be provided by cryptographic modules (PR.AC-2, PR.AC-3, PR.AC-4, 
PR.DS-1, PR.DS-2, PR.DS-5, PR.DS-6, PR.IP-3, and PR.PT-4) and "Detection" of failures or 
other exception conditions that might affect the protection afforded to systems by 
cryptographic modules (DE.CM-1, DE.CM-2, and DM.DP-3). 

2. Guide for Applying the Risk Management Framework to Federal Information Systems: A 
security Lifecycle Approach, NIST Special Publication, SP 800-37 Rev. 1, Joint Task Force 
Transformation Initiative; February 2010 with updates as of June 5, 2014. 

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-37rl.pdf 

SP 800-37 Rev. 1 provides guidelines for applying the Risk Management Framework (RMF) 
to federal information systems. Systems to which the RMF is to be applied include NCCoE 
use case and block activities. The RMF promotes the concept of near real-time risk 
management and ongoing information system authorization through the implementation 
of robust continuous monitoring processes; provides senior leaders with the necessary 
information to make cost-effective, risk-based decisions with regard to the organizational 
information systems supporting their core missions and business functions; and integrates 
information security into the enterprise architecture and development life cycle. Applying 
the RMF within enterprises links management processes at the information system level to 
management processes at the organization level through a risk executive (function) and 
establishes lines of responsibility and accountability for security controls deployed within 
organizational information systems and inherited by those systems (i.e., common controls). 


The six-step RMF includes security categorization, security control selection, security 
control implementation, security control assessment, information system authorization, 
and security control monitoring. With respect to the Cybersecurity Framework, SP 800-37 
assumes that system components, business environment and governance structure have 
been identified. The risk assessment that underlies categorization is based on the assumed 
understanding of these factors. SP 800-37 also focuses on impacts of security incidents 
rather than on threats that take advantage of system vulnerabilities to create those 
impacts. The control selection, control implementation, and system authorization 
recommendations of SP 800-37 do not map directly to the Cybersecurity Framework. 
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However, SP 800-37 does provide recommendations relevant to Identify (ID.RA-5, ID.RA-6, 
ID.RM 1, and ID.RM-2 in Section 3.1), Protect (PR.IP-3, and PR.IP-7 in Sections 3.4 and 3.6), 
and Detect, (DE.AE-5 and DE.CM-1 in Section 3.6) elements of the Cybersecurity 
Framework. 

3. Guidelines on Electronic Mail Security ; NIST Special Publication; SP 800-45 Ver. 2; Tracy, 
Jansen, Scarfone, Butterfield; February 2007. 

http://csrc.nist.gov/publications/nistpubs/800-45-version2/SP800-45v2.pdf 

SP 800-45 provides guidelines intended to assist organizations in installing, configuring, and 
maintaining secure mail servers and mail clients. Specifically, the publication discusses in 
detail: 


a. email standards and their security implications 
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b. email message signing and encryption standards 

c. the planning and management of mail servers 

d. securing the operating system underlying a mail server 

e. mail-server application security 

f. email-content filtering 

g. email-specific considerations in the deployment and configuration of network 
protection mechanisms, such as firewalls, routers, switches, and intrusion detection 
and intrusion prevention systems 

h. securing mail clients 

i. administering the mail server in a secure manner, including backups, security 

As suggested by its 2007 publication date, SP 800-45 doesn't reflect the most recent 
developments in electronic mail security, especially the more recent IETF RFCs (e.g., 
SMIMEA 12 and TLSA 13 ), but the recommendations it makes are still germane. 

With respect to the Cybersecurity Framework's Identify category and its subcategories, SP 
800-45 recommends risk management activities, but does not go into detail that maps to 
subcategory references. In the Protect category, subcategory references PR.AC-1, PR.AC-3, 
PR.AC-4, PR.AC-5, PR.AT-1, PR.AT-2, PR.AT-5, PR.DS-2, PR.DS-6, PR.IP-2, PR.IP-4, and PR.PT-1 
are addressed by the guideline. In the Detect category, subcategory references DP-1 and 
DE.DP-4 are addressed by the guideline. In the Respond category, subcategory references 
DE.AE-2, DE.CM-1, DE.CM-4, DE.CM-5, DE.CM-8, DE.DP-1, and DE.DP-4 are addressed. In 
the Respond category, subcategory references RS.RP-1, RS.CO-1, RS.CO-2, RS.AN-1, and 
RS.IM-1 are addressed by the guideline. In the Recover category, subcategory reference 
RC.RP-1 is addressed by the guideline. 

Federal S/MIME V3 Client Profile, NIST Special Publication, SP 800-49, Chernick, November 
2002. http://csrc.nist.gov/publications/nistpubs/800-49/sp800-49.pdf 


12. See Using Secure DNS to Associate Certificates with Domain Names For S/MIME 
(draft-ietf-dane-smime-02) and Using Secure DNS to Associate Certificates with Domain Names 
For S/MIME (draft-ietf-dane-smime-12) 

13. RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security 
(TLS) Protocol: TLSA 
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5. 


SP 800-49 was developed to provide organizations with approaches to assure that 
Secure/Multipurpose Internet Mail Extensions (S/MIME) products can interoperate and 
meet the e-mail security needs of federal agencies both with respect to security features 
and adequate cryptographic algorithms. This profile states requirements for 

implementing sets of cryptographic algorithm suites specified elsewhere by the standards 
development organizations. The profile specifies a set of e-mail security features (e.g., 
encrypted e-mail and signed receipts) that are mandatory for federal agencies. SP 800-49 
adds specificity to the S/MIME standards, while attempting to avoid violating those 
standards. As its 2002 publication date suggests, SP 800-49 is even more dated with respect 
to protocols than SP 800-45 (e.g., recommending the now deprecated SHA-1 instead of 
SHA-2 for hashing, and the deprecated Triple DES rather than AES for encryption). However, 
it too, makes security recommendations that are still germane. The SP 800-49 requirements 
and recommendations fall into the Cybersecurity Framework Protect category. It provides 
guidelines that address the subcategory references PR.DS-2, PR.DS-6, and (less precisely) 
PR.PT-4. 

Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) 
Implementations; NIST Special Publication; SP 800-52 Rev. 1; Polk, McKay, Chokhani; April 
2014. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52rl.pdf 

Transport Layer Security (TLS) provides mechanisms to protect sensitive data during 
electronic dissemination across the Internet. SP 800-52 provides guidance in the selection 
and configuration of TLS protocol implementations, while making effective use of Federal 
Information Processing Standards (FIPS) and NIST- recommended cryptographic algorithms. 
SP 800-52 requires that TLS 1.1 be configured with FIPS-based cipher suites as the minimum 
appropriate secure transport protocol and recommended that agencies develop migration 
plans to TLS 1.2 by January 1, 2015. This Special Publication also identifies TLS extensions 
for which mandatory support must be provided and some other recommended extensions. 
Like SP 800-49, the SP 800-52 requirements and recommendations fall into the 
Cybersecurity Framework Protect category. The guideline addresses the subcategory 
references PR.DS-2, PR.DS-6, and (less precisely) PR.PT-4. 


6 . Security and Privacy Controls For Federal Information Systems And Organizations, NIST 
Special Publication, SP 800-53 Rev. 4, Joint Task Force Transformation Initiative, April 2013. 

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf 
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SP 800-53 provides a catalog of security and privacy controls for federal information 
systems and organizations and a process for selecting controls to protect organizational 
operations (including mission, functions, image, and reputation), organizational assets, 
individuals, other organizations, and the nation from a diverse set of threats, including 
hostile cyberattacks, natural disasters, structural failures, and human errors. The controls 
are customizable and implemented as part of an organization-wide process that manages 
information security and privacy risk. The controls address a diverse set of security and 
privacy requirements across the federal government and critical infrastructure that are 
derived from legislation, Executive Orders, policies, directives, regulations, standards, 
and/or mission/business needs. The publication also describes how to develop specialized 
sets of controls, or overlays, that are tailored for specific types of missions/business 
functions, technologies, or environments of operation. Finally, the catalog of security 
controls addresses security from both a functionality perspective (the strength of security 
functions and mechanisms provided) and an assurance perspective (the measures of 
confidence in the implemented security capability). Addressing both security functionality 
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and security assurance ensures that information technology products and the information 
systems built from those products using sound systems and security engineering principles 
are sufficiently trustworthy. 

SP 800-53 Rev. 4 addresses all Cybersecurity Framework categories and subcategories. Only 
the RC.CO-1 (Reputation after an event is repaired) and RC.CO-2 (Recovery activities are 
communicated to internal stakeholders and executive and management teams) references 
under the Recover: Communications subcategory are not addressed by SP 800-53. 

7. Recommendation for Key Management: Part 1 - General, NIST Special Publication 800-57 
Part Rev.4, Barker, January 2016; Part 2 - Best Practices for Key Management Organization, 
NIST Special Publication 800-57 Part 2, Barker, Barker, Burr, Polk, and Smid, August 2005; 
and Part 3 - Application-Specific Key Management Guidance, NIST Special Publication, SP 
800-57 Part 3 Rev. 1, Barker and Dang, January 2015. 

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57ptlr4.pdf, 
http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part2.pdf, 
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-57Pt3rl.pdf 

NIST Special Publication 800-57 provides cryptographic key management guidance. Part 1 
provides general guidance and best practices for the management of cryptographic keying 
material. Part 2 provides guidance on policy and security planning requirements for U.S. 
government agencies. Part 3 of this Special Publication provides guidance when using the 
cryptographic features of current systems that may not exhibit all of the properties 
recommended by Part 1 of the guideline. Part 3 includes applications-specific 
recommendations for, among other applications, the Public Key Infrastructure (PKI), 
Internet Protocol Security (IPsec), Transport Layer Security (TLS) Secure/Multipart Internet 
Mail Extensions (S/MIME), and Domain Name System Security Extensions (DNSSEC). All of 
these recommendations apply directly to the DNS-Based E-Mail Security Building Block. 

SP 800-57 addresses all of the Cybersecurity Framework categories except Detect. Audit is 
the primary mechanism relied on in SP 800-53 for detection purposes. The categories and 
subcategory references that are addressed by the guideline include Identify (ID.AM-2, 
ID.BE-3, ID.BE-4, ID.BE-5, ID.GV-1, ID.GV-4, ID.RA-4,and ID.RA-5), Protect (PR.AC-1, PR.AC-2, 
PR.AC-3, PR.AC-4, PR.AT-2, PR.AT-3, PR.AT-4, PR.DS-1, PR.DS-2, PR.DS-3, PR.DS-4, PR.DS-6, 
PR.IP-2, PR.IP-3, PR.IP-4, PR.IP-5, PR.IP-6, PR.IP-9, PR.PT-1, PR.PT-2, PR.PT-3, and PR.PT-4); 
Respond (RS.RP-1, RS.CO-1, RS.CO-2, RS.CO-3, RS.AN-2, and RS.MI-2); and Recover 
(RC.RP-1). 

8 . Secure Domain Name System (DNS) Deployment Guide, NIST Special Publication, SP 
800-81-2, Chandramouli and Rose, September 2013. 

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf 

The DNS is a distributed database that enables access to Internet resources via user-friendly 
domain names, rather than IP addresses, by translating domain names to IP addresses and 
back. The DNS infrastructure is made up of computing and communication entities called 
name servers, each of which contains information about a small portion of the domain 
name space. The name data provided by DNS is intended to be available to any computer 
located anywhere in the Internet. SP 800-81-2 provides deployment guidelines for securing 
DNS within an enterprise. The primary security goals for DNS are data integrity and source 
authentication, which are needed to ensure the authenticity of name information and 
maintain the integrity of name information in transit. This document provides extensive 
guidance on maintaining data integrity and performing source authentication. This 
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document presents guidelines for configuring DNS deployments to prevent many 
redirection attacks that exploit vulnerabilities in various DNS components. 

The categories and subcategory references that are addressed are limited to Identify 
(ID.AM-2 and ID.RA-6), Protect (PR.AC-1, PR.AC-3, PR.AC-5, PR.AT-2, PR.DS-2, PR.DS-5, 
PR.DS-6, PR.IP-3, PR. I P-4, PR.IP-6, and PR.IP-9), and Detect (DE.CM-1 and DE.CM-7). 

9. A Framework for Designing Cryptographic Key Management Systems ; NIST Special 
Publication; SP 800-130; Barker, Branstad, Smid, Chokhani; August 2013. 

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-130.pdf 

SP 800-130's framework for Designing Cryptographic Key Management Systems (CKMS) 
contains topics that should be considered by a CKMS designer when developing a CKMS 
design specification. For each topic, there are one or more documentation requirements 
that need to be addressed by the design specification. Thus, any CKMS that addresses each 
of these requirements would have a design specification that is compliant with this 
framework. A CKMS will be a part of a larger information system that executes processing 
applications. While the CKMS supports these applications by providing cryptographic key 
management services, the particular applications or particular classes of applications are 
beyond the scope of this framework. 

SP 800-130 addresses all of the Cybersecurity Framework categories The categories and 
subcategory references that are addressed include Identify (ID.BE-4, ID.GV-1, ID.GV-2, 
ID.GV-3, ID.GV-4, ID.RA-1, ID.RA-2, ID.RA-3, ID.RA-5, and RM-1); Protect (PR.AC-1, PR.AC-2, 
PR.AC-4, PR.AC-5, PR.AT-1, PR.AT-2, PR.AT-4, PR.AT-5, PR.DS-1, PR.DS-2, PR.DS-3, PR.DS-6, 
PR.DS-7, PR.IP-1, PR.IP-3, PR.IP-4, PR.IP-5, PR.IP-6, PR.IP-9, PR.MA-1, PR.PT-1, PR.PT-2, 
PR.PT-3, and PR.PT-4); Detect (DE.AE-4, DE.CM-1, DE.CM-4, DE.CM-7, DE.CM-8,DE.DP-1, 
DE.DP-2, DE.DP-3, and DE.DP-5); Respond (RS.RP-1, RS.CO-1, RS.CO-2, RS.AN-2, RS.MI-1, 
and RS.MI-2); and Recover (RC.RP-1). 

10. A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS); Third Draft; NIST 
Special Publication; SP 800-152; Barker, Smid, Branstad; December 18, 2014. 

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-152.pdf 

Draft SP 800-152 covers major aspects of managing the cryptographic keys that protect 
federal information. Associated with each key is specific information (e.g., the owner 
identifier, its length, and acceptable uses) called metadata. The computers, software, 
modules, communications, and roles assumed by one or more authorized individuals when 
managing and using cryptographic key management services are collectively called a 
Cryptographic Key Management System (CKMS). The Profile for U. S. Federal Cryptographic 
Key Management Systems (FCKMSs) has been prepared to assist CKMS designers and 
implementers in selecting the features to be provided in their "products," and to assist 
federal organizations and their contractors when procuring, installing, configuring, 
operating, and using FCKMSs. 

SP 800-130 addresses all of the Cybersecurity Framework categories. The categories and 
subcategory references that are addressed include Identify (ID.AM-3, ID.AM-5, ID.BE-4, 
ID.BE-5, ID.GV-1, ID.GV-2, ID.GV-3, ID.GV-4, ID.RA-1, ID.RA-3, ID.RA-5, ID.RA-6, RM-1, and 
RM-2); Protect (PR.AC-1, PR.AC-2, PR.AC-3, PR.AC-4, PR.AC-5, PR.AT-1, PR.AT-2, PR.AT-4, 
PR.AT-5, PR.DS-1, PR.DS-2, PR.DS-3, PR.DS-4, PR.DS-6, PR.DS-7, PR.IP-1, PR.IP-3, PR.IP-4, 

PR.IP-5, PR.IP-6, PR.IP-7, PR.IP-8, PR.IP-9, PR.IP-12, PR.MA-1, PR.PT-1, PR.PT-2, PR.PT-3, and 
PR.PT-4); Detect (DE.AE-4, DE.CM-1, DE.CM-4, DE.CM-7, DE.CM-8, DE.DP-1, DE.DP-2, 


DNS-Based Email Security Practice Guide 


28 




Chapter 4. Approach 


DE.DP-3, and DE.DP-5); Respond (RS.RP-1, RS.CO-l, RS.CO-2, RS.AN-2, RS.MI-1, RS.MI-2, 
RS.MI-3, and RS.IM-2); and Recover (RC.RP-1 and RC.IM-2). 

11. Trustworthy Email; NIST Special Publication 800-177; Chandramouli, Garfinkle, Nightingale 
and Rose; Draft Publication; September 2016. 

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177.pdf 

NIST Special Publication 800-177 serves as a complimentary document to SP 800-45. SP 
800-177 addresses email protocol security and provides descriptions, guidelines and 
recommendations for deploying new email security protocols such as SMTP over TLS, email 
supported by DANE, and other non-cryptographic authentication (e.g. Sender Policy 
Framework, etc.). Discussions of SMTP over TLS and S/MIME relate directly to the work on 
the DNS-Based Email Security Project builds. 

With respect to the Cybersecurity Framework's Identify category and its subcategories, SP 
800-177 recommends risk management activities, but does not go into detail that maps to 
subcategory references. In the Protect category, subcategory references PR.AC-1, PR.AC-3, 
PR.AC-4, PR.AC-5, PR.AT-1, PR.AT-2, PR.AT-5, PR.DS-2, PR.DS-6, PR.IP-2, PR.IP-4, and PR.PT-1 
are addressed by the guideline. In the Detect category, subcategory references DP-1 and 
DE.DP-4 are addressed by the guideline. In the Respond category, subcategory references 
DE.AE-2, DE.CM-1, DE.CM-4, DE.CM-5, DE.CM-8, DE.DP-1, and DE.DP-4 are addressed. In 
the Respond category, subcategory references RS.RP-1, RS.CO-l, RS.CO-2, RS.AN-1, and 
RS.IM-1 are addressed by the guideline. In the Recover category, subcategory reference 
RC.RP-1 is addressed by the guideline. 


4.4.6 Other Security References Applied in the Design and Development 
of the DNS-Based Email Security Project 

The following references provided additional security and protocol standards and guidelines 
that were applied during design and development of the DNS-Based Email Security Project. 

1. Systems Security Engineering: An Integrated Approach to Building Trustworthy Resilient 
Systems, Draft, NIST Special Publication, SP 800-160, May 2014. 

http://csrc.nist.gov/publications/drafts/800-160/sp800_160_second-draft.pdf 

NIST Special Publication 160 defines system security engineering processes that are tightly 
coupled to and fully integrated into well-established, international standards-based systems 
and software engineering processes. The project supports the federal cybersecurity 
strategy of "Build It Right, Continuously Monitor" and consists of a four-phase development 
approach that will culminate in the publication of the final systems security engineering 
guideline at the end of 2014. The four phases include: 

a. Phase 1: Development of the system security engineering technical processes based on 
the technical systems and software engineering processes defined in ISO/IEC/IEEE 
15288:2008 

b. Phase 2: Development of the remaining supporting appendices (i.e., Information 
Security Risk Management (including the integration of the Risk Management 
Framework [RMF], security controls, and other security- and risk-related concepts into 
the systems security engineering processes), Use Case Scenarios, Roles and 
Responsibilities, System Resiliency, Security and Trustworthiness, Acquisition 
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Considerations, and the Department of Defense Systems Engineering Process (Summer 
2014) 

c. Phase 3: Development of the systems security engineering nontechnical processes 
based on the nontechnical systems and software engineering processes (i.e., 
Agreement, Organizational Project-Enabling, and Project) defined in ISO/IEC/IEEE 
15288: 2008 (Fall 2014) 

d. Phase 4: Alignment of the technical and nontechnical processes based on the updated 
systems and software engineering processes defined in ISO/IEC/IEEE DIS 15288:201x(E) 
(Fall or Winter 2014, subject to the final publication schedule of the international 
standards bodies) 


The full integration of security engineering discipline into the systems and software 
engineering discipline involves fundamental changes in the traditional ways of doing 
business within organizations. This may involve breaking down institutional barriers that, 
over time, have isolated security activities from the mainstream organizational 
management and technical processes, including, for example, the system development life 
cycle, acquisition/procurement, and enterprise architecture. The integration of these 
interdisciplinary activities requires the strong support of senior leaders and executives, and 
increased levels of communication among all stakeholders who have an interest in, or are 
affected by, the systems being developed or enhanced. 


2. Internet X.509 Public Key Infrastructure Certificate and CRL Profile; IETF RFC 2459; Flousley, 
Ford, Polk, Solo; January 1999. https://www.rfc-editor.org/rfc/rfc2459.txt 

RFC 2459 is one part of a family of standards for the X.509 Public Key Infrastructure (PKI) for 
the Internet, but the RFC is a standalone document; implementations of this standard 
proceed independent from the other parts. The RFC profiles the format and semantics of 
public key certificates and certificate revocation lists for the Internet. Procedures are 
described for the processing of certification paths in the Internet environment. Encoding 
rules are provided for popular cryptographic algorithms. Finally, ASN.l modules are 
provided in the appendices for all data structures defined or referenced. 


3. Threat Analysis of the Domain Name System (DNS), IETF RFC 3833, Atkins and Austein, 
August 2004. https://tools.ietf.org/html/rfc3833 


RFC 3833 attempts to document some of the known threats to the DNS, and, in doing so, 
measure the extent to which DNSSEC is a useful tool in defending against these threats. 

4. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) 
Profile; Proposed Standard; IETF RFC 5280; Cooper, Santesson, Farrell, Boeyen, Flousley, 
Polk; May 2008. https://datatracker.ietf.org/doc/rfc5280/ 

RFC 5280 profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for 
use in the Internet. The RFC provides an overview and model of the specified approach, 
describes the X.509 v3 certificate format in detail, with additional information regarding the 
format and semantics of Internet name forms. Standard certificate extensions are 
described and two Internet-specific extensions are defined. A set of required certificate 
extensions is also specified, the X.509 v2 CRL format is described along with standard and 
Internet-specific extensions, an algorithm for X.509 certification path validation is 
described, and an ASN.l module and examples are provided. 


5. Simple Mail Transfer Protocol, IETF RFC 5321, Draft Standard, Kleinstein, October 2008. 

https://tools.ietf.org/html/rfc5321 
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RFC 5321 is a specification of the basic protocol for Internet electronic mail transport. It 
covers the SMTP extension mechanisms and best practices for the contemporary Internet, 
but does not provide details about particular extensions. Although SMTP was designed as a 
mail transport and delivery protocol, this specification also contains information that is 
important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading 
systems and mobile environments. 

6 . Secure/Multipurpose Internet Mail Extensions (S/MIME), Version 3.2, Message 

Specification, Proposed Standard, IETF RFC 5751, ISSN: 2070-1721, Ramsdell and Turner, 
January 2010. https://tools.ietf.org/html/rfc5751 

RFC 5751 defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. 
S/MIME provides a consistent way to send and receive secure MIME data. The RFC 
describes methods for digital signatures to provide authentication, message integrity, and 
non-repudiation with proof of origin; encryption to provide data confidentiality; and to 
reduce data size. 


7. Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE), IETF 
RFC 6394, ISSN: 2070-1721, Barnes, October 2011. https://tools.ietf.org/html/rfc6394 

Many current applications use the certificate-based authentication features in Transport 
Layer Security (TLS) to allow clients to verify that a connected server properly represents a 
desired domain name. Typically, this authentication has been based on PKI certificate chains 
rooted in well-known certificate authorities (CAs), but additional information can be 
provided via the DNS itself. This document describes a set of use cases in which the DNS and 
DNS Security Extensions (DNSSEC) could be used to make assertions that support the TLS 
authentication process. The main focus of this document is TLS server authentication, but it 
also covers TLS client authentication for applications where TLS clients are identified by 
domain names. 


8 . The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security Protocol: 
TLSA, Proposed Standard, IETF RFC 6698, ISSN: 2070-1721, Floffman and Schlyter, August 
2012. https://tools.ietf.org/html/rfc6698 

Encrypted communication on the Internet often uses Transport Layer Security (TLS), which 
depends on third parties to certify the keys used. RFC 6698 provides means to improve on 
that situation by standardizing on methods to enable the administrators of domain names 
to specify the keys used in that domain's TLS servers. This requires matching improvements 
in TLS client software, but no change in TLS server software. 

9. Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate 
Revocation List (CRL) Profile, Proposed Standard, IETF RFC 6818, ISSN: 2070- 1721, Yee, 
January 2013. https://tools.ietf.org/html/rfc6818 


RFC 6818 updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and 
Certificate Revocation List (CRL) Profile. It changes the set of acceptable encoding methods 
for the explicit Text field of the user notice policy qualifier and clarifies the rules for 
converting internationalized name labels to ASCII. The RFC also provides some clarifications 
on the use of self-signed certificates, trust anchors, and some updated security 
considerations. 


10. SMTP security via opportunistic DANE TLS, RFC 7672, Dukhovni and Flardaker, May 26, 2015. 

https://tools.ietf.org/html/rfc7672 
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The RFC describes a downgrade-resistant protocol for SMTP transport security between 
Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named 
Entities (DANE) TLSA DNS record. Adoption of this protocol will enable an incremental 
transition of the Internet email backbone to one using encrypted and authenticated 
Transport Layer Security (TLS). 

11. Using Secure DNS to Associate Certificates with Domain Names For S/MIME, IETF Internet 
Draft Work in Progress, draft-ietf-dane-smime-12, Floffman and Schlyter, July 31, 2016. 

https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ 

The draft RFC for using secure DNS to associate certificates with domain names for S/MIME 
describes how to use secure DNS to associate an S/MIME user's certificate with the 
intended domain name; similar to the way that DANE (RFC 6698) does for TLS. 


4.5 Technologies 

The laboratory configuration employed for the DNS-Based Email Security project included 
components contributed by several sets of collaborating organizations. One of the component 
sets is Windows-based. The others are Linux-based. There were also three Mail User Agents 
(MUAs): Microsoft Outlook, Mozilla Thunderbird (on Linux), and a Thunderbird MUA equipped 
with a DANE-aware Apple Key Chain utility 14 that were able to interact to all the mail servers via 
IMAP. While the Windows-based contribution used Server 2016 DNS services, the Linux-based 
contributions included three different implementations for DNS. One was based on NSD4 and 
Unbound authoritative and recursive servers, one was based on the Berkeley Internet Name 
Domain (BIND) DNS server, and one was based on the Secure64 DNS services. Secure 64 also 
contributed DNS services hosted on dedicated processors using SecureT micro O/S technology. 
Collaborators assisted in installation and initial configuration of products and, as necessary, in 
composition of components for different test cases. 

Figure 4.1 below depicts, at a high-level, collaborator contributions used to support the 
demonstration project. Elements identified in boldface are components provided or adapted by 
the collaborator. Other elements were incorporated into the stack to permit checking out the 
installed component's functionality. 

Collaborator contributions identified below are organized with respect to the contributor as 
initially installed and checked out at the NCCoE. The architecture described in Section 5 below 
permits demonstration of the interconnection of components provided by different 
collaborators and initially checked out independently. 


14. A utility for Public Key Retrieval into the Apple Key Chain. This utility is delivered on a Mac- 
Book loaded with Apple Mail and is a program for the MacBook that will fetch SMIMEA records 
and put them in the keystore so that we can demonstrate end-to-end security. 
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Figure 4.1 DNS-Based Email Security Collaborator Contributions 
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BS0 4.5.1 Microsoft 

nsi The Microsoft environments were contributed to support demonstration Scenario 1. Two 

Bs 2 environments were configured on the laboratory's VMware virtual machines (See figure 4.1 

bs 3 above). Each stack included the ability to demonstrate Office Outlook 15 as an MUA, included 

854 Exchange Server 2016 16 as MTAs, and used Active Directory running on Microsoft Windows 

85 5 Server 2016 17 for DNS services. The Microsoft contribution included DNSSEC aware DNS 

856 recursive server, DNSSEC aware DNS authoritative server (IETF RFC 4033, 4034, and 4035), an 

as? MTA that can do SMTP over TLS (RFC 3207), management tools to configure servers and for 

ass debugging purposes, X.509 certificate sources, FIPS 140-2 validated cryptographic software, 

859 and support for multifactor authentication. The stacks were also able to be configured to 

860 demonstrate that Exchange could be used with either an Outlook or a Thunderbird MUA. Other 

861 test cases demonstrated using Exchange with a combination of other providers' DNS 

862 implementations. 


15. https://en.wikipedia.org/wiki/Microsoft_Outlook 

16. https://products.office.com/en/exchange/microsoft-exchange-server-2016 

17. https://www.microsoft.com/en-us/server-cloud/products/windows-server-2016/ 
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843 4.5.2 NLnet 

864 The NLnet contribution focused on DNS services to support both demonstration scenarios. 

865 NLnet software was initially configured on the laboratory's VMware virtual machines. The 

866 components included NSD4 4.1.9 18 , Unbound 19 , and OpenDNSSEC 20 software for DNS services 

867 and Postfix and Dovecot for mail services. NSD4 is an authoritative only, high performance, 

868 open source name server. Unbound is a validating, recursive, caching DNS resolver. 

869 OpenDNSSEC is a set of software for signing DNS zones that are then served using NSD. While 

870 OpenDNSSEC can be configured to sign zone files or to sign zones transferred in via DNS zone 

871 transfer (AXFR), in these scenarios, it is used to sign local zone files in these scenarios. Like with 

872 the Microsoft stack above, multiple MUAs were configured to send and receive mail with the 

873 NLnet components via SMTP and IMAP. 


87 4 4.5.3 ISC 

875 The ISC contribution was focused on the BIND DNS server and supported both demonstration 

876 scenarios. BIND was initially configured on the laboratory's VMware virtual machines and 

a?? included configuration for Postfix and Dovecot for email. BIND 21 is open source software that is 

878 considered the reference implementation of DNS, but it is also production-grade software, 

879 suitable for use in high-volume and high-reliability applications. BIND features response rate 

880 limiting (RRL), support for FIPS 140-2 validated hardware cryptographic modules, the optional 

881 ability to retrieve zone data directly from an external database, the ability to use in-line signing 

882 to automatically re-sign records as they are updated, and a scalable master/slave hierarchy. Like 

883 the other stacks, all three MUAs were able to connect and use the stack for DNS and email. 


884 4.5.4 Secure64 

ass The Secure64 contributions were focused on DNS services to support both demonstration 

886 scenarios. The Secure64 environment included an automated online Secure64 DNS Signer as 

as? well as DNSSEC-capable VM images of DNS Cache, DNS Authority, and DNS Manager. DNS 

888 Manager provided centralized management of Secure64 DNS Cache software and 

889 configurations and provided network-wide monitoring of key performance indicators. DNS 

890 Manager allowed creation of groups of servers and assignment of configurations to a group, a 

B9i single server, or all servers. DNS Authority is an authoritative signer and server as a single 

892 platform. DNS Cache, DNS Authority, and DNS Manager were configured on the laboratory's 

893 VMware virtual machine; and the DNS Signer was provided as a high-assurance implementation 

894 delivered on a Secure64 dedicated appliance. Secure64 contributions were able to demonstrate 

895 Outlook, Thunderbird, or Thunderbird equipped with an Apple Key Chain utility as MUAs and 

896 use Postfix as an MTA and Dovecot to provide IMAP for clients. 


18. http://www.nlnetlabs.nl/projects/nsd/ 

19. http://unbound.net 

20 . https://www.opendnssec.org 

21 . https://www.isc.org/downloads/bind/ 
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The Security platform architecture used for the DNS-Based Email Security project included 
combinations of components from different sources that supported two usage scenarios for 
DANE-enabled secure email in four different systems environments. 


5.1 Usage Scenarios Supported 

The scenarios supported include: 

■ "ordinary" email where the email exchanges between two organizations' email servers 
communicate over TLS with a STARTTLS extension, and relevant TLSA records are published 
in the receiver's DNS zone protected by DNSSEC; and 

■ end-to-end signed email, where the email exchanges between users in different 
organizations are carried over a channel protected by TLS (using the STARTTLS extension), 
and relevant artifacts used for signing and channel protection are published in a DNS zone 
protected by DNSSEC. Subsequently, these artifacts are used for S/MIME and TLS validation. 

In both scenarios, end-entity and personal certificates were generated from Certificate 
Authorities (CAs). Use of "well known" (i.e. installed as trust anchors in hosts), local enterprise 
CAs, and self-signed certificates were demonstrated. 

While the second scenario demonstrated signing of emails, it does not include an end-to-end 
encrypted email scenario. Signing addresses the main security concerns in enterprise 
environments, which are the target of the project, but may neglect concerns of individual users 
who may also want to reduce information disclosure to their email providers. The two 
scenarios that are included may, however, serve as enablers for end-to-end encryption. 
Participation by parties having a primarily end-to-end encryption focus may succeed in 
generating industry support for the building blocks needed to support end-to-end encryption. 

In more detail, the project's security platforms use the STARTTLS extension to include 
encryption of communications between two MTAs, as well as the signature of individual 
messages using S/MIME. The encryption and decryption with S/MIME on the end user's client 
was excluded from the current platform demonstration. 

5.1.1 Usage Scenario 1 

An individual needs to enter into an email exchange with an individual in another organization 
Each individual exchanges email via the respective parent organizations' mail servers. Users 
connect to their organizations' respective mail servers within a physically protected zone of 
control. 

In this scenario, the privacy policy of the parent organizations requires encryption of the 
information being exchanged. The security afforded by the cryptographic process is dependent 
on the confidentiality of encryption keys from unauthorized parties. The mail servers are 
configured to use X.509 certificates to authenticate themselves during an encryption key 
establishment process. 
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DNSSEC is employed to ensure that each sending mail server connects to the legitimate and 
authorized receiving mail server from which its X.509 certificate is obtained. DANE resource 
records are employed to bind the cryptographic keying material to the appropriate server 
name. STARTTLS is employed to negotiate the cryptographic algorithm to be employed with TLS 
in the email exchange in which the Pll is transferred. Encryption of the email message is 
accomplished by the originator's email server, and decryption of the email message is 
accomplished by the recipient's email server. 

Demonstrations of the security platform in this scenario include an attempt by a fraudulent 
mail server to pose as the legitimate receiver of the email and a man-in-the-middle attacker to 
attempt to disrupt the signal that TLS is available for the desired destination. In the latter 
attack, the goal is to force unencrypted transmission of the email. Both attempts should fail due 
to use of DNSSEC and DANE. 


5.1.2 Usage Scenario 2 

An individual needs to enter into an email exchange with an individual in another organization. 
Each individual exchanges email via the respective parent organizations' mail servers. Users 
connect to their organizations' respective mail servers within a physically protected zone of 
control. 

The policy of the parent organizations requires cryptographic digital signature of the message 
to provide integrity protection source authentication of the email message. S/MIME is a widely 
available and used protocol for digitally signing electronic mail. Each organization has therefore 
generated X.509 certificates for their users that include the public portion of their signature 
keys. These certificates are then published in the DNS using the appropriate DANE DNS 
Resource Record (RR) type. 

DNSSEC is used to provide assurance that the originating user's mail server connects to the 
intended recipient's mail server. DANE records are employed to bind the cryptographic 
certificates to the appropriate server (for TLS) and individual user (for S/MIME), respectively. 
TLS is employed to provide confidentiality. Digital signature of the email message is 
accomplished by the originator's email client. Validating the signature (hence the integrity of 
the authorization provided in the email message) is accomplished by the recipient's email 
client. 

Demonstrations of the security platform in this scenario include an attempt by a fraudulent 
actor to pose as the originator of the email and a man-in-the-middle attacker attempting to 
disrupt the validation the S/MIME signature. Both attempts fail due to use of DNSSEC and DANE 
records. 
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5.2 Architectural Overview 

The laboratory architecture for the DNSSEC-Based Email Security project was designed to 
permit interconnection of Microsoft Outlook and Thunderbird MUAs with Microsoft Exchange 
and Postfix/Dovecot MTAs. It demonstrates the interconnection of either MTA with any of the 
DNS services contributed by collaborators. Two instantiations of each MTA type were 
established to demonstrate email exchanges between MTAs of the same type or different 
types. The various component combinations are then demonstrated with three different TLSA 
RR parameters: a self-signed certificate, use of local certificate authorities, and use of 
well-known certificate authorities. 

Figure 5.1 is a deployment diagram of the architecture used for demonstrating DNS-Based 
Email Security. 

Figure 5.1 DNS-Based Email Security Deployment Diagram 





Email Clients 





Mail User Agent 
Thunderbird With 
Apple Key Chain 
Utility 



For test documentation purposes, the receiving MTA is named differently depending on the 
receiver's DNS service zone and the TLSA option being demonstrated. The sending MTA's 
implementation and DNS infrastructure can also vary for each test, but share the same basic 
processes. 
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The design of the environment permits interconnection of components provided by different collaborators (see figure 5.2). 

Figure 5.2 DNS-Based Email Security Test Set-up 



The depiction shows that the project security platform test/demonstration activity was based on three different clients, two MTAs, and 
four DNS service configurations in the lab at the NCCoE exchanging messages with NLnet Labs and Secure64. All messages were signed 
(a mail client function) and encrypted (server to server). We worked with one remote location at a time, driven by whichever is ready 
first. The message exchanges, including DNS activity will be logged at each end (lab and remote correspondent). 
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The solid connectors in the depiction illustrate one case. The dotted lines depict the other cases 
we'll want to demonstrate. A switch convention is used to reflect configuration options, but the 
project team actually configures each component for each option. 

The orange arrows between the mail clients and the Postfix MTA reflect the fact that clients 
submitted email directly to the SMTP server for relay, while using Dovecot only to get mail. (The 
depiction in figure 5.2 reflects that IMAP isn't used to submit mail, only retrieve it, so the MUA 
sent mail directly to the Postfix server, but received the reply through the Dovecot server.) 

The project team demonstrated 30 different events using various combinations of MUA, MTA, 
and DNS Server components divided among five test sequences. In each sequence, signed and 
encrypted messages were sent from a sender to a recipient. Both Exchange and Postfix 
encrypted mail by default. Most of the exchanges employed either self-signed certificates or 
local CAs (see Appendix C). The BIND configuration was set up to obtain and validate 
certificates from the NIST Advanced Networks Technology Division's (ANTD's) DNS source 
(acting as a root CA). (See section 7 below for test sequence sets.) Both Exchange and Postfix 
encrypted mail by default. Most of the exchanges employed either self-signed certificates or 
local CAs. 

In one test sequence, fraudulently S/MIME signed email was sent from a malicious sender to 
recipients using Outlook and Thunderbird MUAs configured to use Exchange and Postfix as 
MTAs. The Outlook/Exchange configuration used Active Directory as its DNS server. The 
configurations employing Postfix/Dovecot MTAs were demonstrated with each of the other 
three contributed DNS Services. In one event, the Thunderbird MUA employed an Apple Key 
Chain Utility tool that allows a host to obtain X.509 certificates via of DANE RRs. All events were 
conducted using well-known CA and Enterprise CA-issued certificates for the impersonated 
sender. The fraudulent site attempted to spoof a valid sending domain belonging to a Secure64 
site that was configured with DNS Authority/Cache/Signer DNS services, a Postfix/Dovecot 
MTA, and Thunderbird equipped with the Apple Key Chain utility. An Outlook/Exchange/ Active 
Directory set-up acted as the fraudulent site. The email exchange between organizations was 
carried over TLS, and the email message was S/MIME signed on the fraudulent users' client 
device. The set-up for this sequence is depicted in figure 5.3 below. 

In another sequence, an NCCoE system attempted to send a TLS protected email from Exchange 
and Postfix MTAs (in turn) to an external Postfix MTA using DNS Authority/Cache/Signer for 
DNS services. The NCCoE Exchange MTA used Active Directory DNS Services, and the 
Postfix/Dovecot MTA used BIND and NSD4/Unbound/OpenDNSSEC DNS services. A S/MIME 
signed email was sent to an external Postfix MTA. Four events were conducted using 
Well-Known CA issued certificates, four events were conducted using Enterprise CA issued 
certificates (TLSA/SMIMEA RR parameter of CU=2) for TLS and S/MIME on the receiver side, 
and three events were conducted using self-signed certificates (TLSA/SMIMEA RR parameter of 
CU=3) for TLS and S/MIME on the receiver side. An Outlook/Exchange/Active Directory stack 
acted as a man-in-the-middle and attempted to intercept the message. Figure 5.4 depicts the 
configuration for a man-in-the-middle demonstration. Note that the sender is being 
misdirected to a malicious email server only. This is to simulate a lower level attack where email 
is sent (via route hijacking or similar low level attack) to a Man-in-the-Middle. Figure 5.4 
depicts the configurations used with the Thunderbird/Postfix/ Dovecot/Bind option selected. 
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Figure 5.3 Fraudulent DNS Address Spoofing Configurations 
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Figure 5.4 Man-ln-The-Middle Event Configurations 



Mail & DNS Information 

The following subsections describe the architecture's MUA, MTA, and DNS service components and Cybersecurity Framework Core 
categories supported by those components. 
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5.2.1 Client Systems and Mail User Agents (MUAs) 

Client systems environments are Microsoft Office, Apple Mail, and open-source Linux-based 
Thunderbird applications. These include both commercial products and open-source software. 
MUA capabilities associated with the client systems are used to invoke S/MIME digital signature 
and signature verification for email, but user-to-user encryption is not demonstrated. 
Collaborators assisted in installation, integration tailoring as necessary, and testing of 
laboratory configurations. 


Table 5.1 Client Systems 


Application 

Source 

Collaborator 
Configuration Support 

Cybersecurity 
Framework Category 

Office Outlook 

Mail User Agent 

Microsoft 

Microsoft 

PR.AC-1, PR.AC-2, 
PR.DS-1, PR.DS-2, 
PR.DS-6, PR.PT-4, 
RS.MI-2 

Thunderbird 

Mail User Agent 

Open (Mozilla) 

NLnet Labs 

PR.AC-1, PR.AC-2, 
PR.DS-1, PR.DS-2, 
PR.DS-6, PR.PT-4, 
RS.MI-2 

Thunderbird with 

Apple Key Chain 

Secure64 

Secure64 

PR.AC-1, PR.AC-2, 
PR.DS-1, PR.DS-2, 
PR.DS-6, PR.PT-4, 
RS.MI-2 


5.2.2 Email Servers 

Email servers include both Windows and Linux-based (Dovecot/Postfix) Mail Transfer Agents. 
Server-to-server encryption was demonstrated in the Postfix environments. Authentication of 
domain and server identity was based on DNSSEC-signed DANE records. Use of these DANE 
records is only supported by Postfix at the time of this project. The MTAs support each of the 
Cybersecurity Framework Functions, Categories, and Subcategories identified in section 4.4.4 
above. The servers were demonstrated in different DNS environments and different TLSA RR 
usage scenarios. In order to demonstrate representative TLSA parameters, the demonstrations 
used self-signed certificates, end-entity certificates generated by well-known CAs and 
end-entities generated by enterprise local CAs. 
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Table 5.2 Mail Transfer Agents 


Application 

Source 

Collaborator Configuration 
Support 

Cybersecurity 
Framework Category 

Exchange 2016 a 

Mail Transfer Agent 

TLS capable 

Microsoft 

Microsoft 

PR.AC-1, PR.AC-2, 

PR.AC-3, PR.AC-5, 
PR.DS-1, PR.DS-239, 
PR.DS-6, PR.PT-439, 
DE.CM-1, DE.CM-2, 

DE.DP-4, RS.RP-1, 

RS.CO-2, RS.MI-2 

Postfix 

Open 

NLnet Labs 

PR.AC-1, PR.AC-2, 

Mail Transfer Agent 

TLS capable 

DANE capable 

(postfix.com) 

Fraunhofer 

Secure64 

PR.AC-3, PR.AC-5, 
PR.DS-1, PR.DS-2, 
PR.DS-6, PR.PT-4, 
DE.CM-1, DE.CM-2, 

DE.DP-4, RS.RP-1, 

RS.CO-2, RS.MI-2 


a. Exchange provided integrity protection only for PR.DS-1, PR.DS-2, and PR.PT-4 (Scenario 2). 


5.2.3 DNS Servers 

Both Windows and Linux-based DNS server and support components were contributed. DNS 
services provided include DNSSEC validating DNS resolvers (stub and recursive) and 
authoritative DNS servers for DNSSEC signed zones. Support for SMIMEA and TLSA records was 
demonstrated. The DNS server components support each of the Cybersecurity Framework 
Functions, Categories, and Subcategories identified in section 4.4.4 above with the exception of 
PR.DS-1 (protection of data-at-rest). 


Table 5.3 DNS Servers 


Application 

Source 

Collaborator 
Configuration Support 

Cybersecurity 
Framework Category 

Active Directory and 
Windows Server 2016 

■ Supports DNSSEC 

Microsoft 

Microsoft 

PR.AC-1, PR.AC-2, 

PR.AC-3, PR.AC-5, 
PR.DS-2, PR.DS-6, 

PR.PT-4, DE.CM-1, 
DE.CM-2, DE.DP-4, 
RS.RP-1, RS.CO-2, 

RS.MI-2 

BIND 3 

■ Supports DNSSEC 

■ Supports DANE 

Open (ISC) 

Internet Systems 
Consortium (ISC) 

PR.AC-1, PR.AC-2, 

PR.AC-3, PR.AC-5, 
PR.DS-2, PR.DS-6, 

PR.PT-4, DE.CM-1, 
DE.CM-2, DE.DP-4, 
RS.RP-1, RS.CO-2, 

RS.MI-2 
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Table 5.3 DNS Servers 


Application 

Source 

Collaborator 
Configuration Support 

Cybersecurity 
Framework Category 

NSD4 

■ Supports DNSSEC 

■ Supports DANE 

Unbound 

■ Supports DNSSEC 

OpenDNSSEC 

Open (NLnet Labs) 

Open (NLnet Labs) 

PR.AC-1, PR.AC-2, 

PR.AC-3, PR.AC-5, 
PR.DS-2, PR.DS-6, 

PR.PT-4, DE.CM-1, 
DE.CM-2, DE.DP-4, 
RS.RP-1, RS.CO-2, 

RS.MI-2 

DNS AUTHORITY 

DNS MANAGER 

■ Supports DNSSEC 

■ Supports DANE 

(Caching authority is 
labeled DNS CACHE, 
and signer runs on a 
dedicated processor) 

Secure64 

Secure64 

PR.AC-1, PR.AC-2, 

PR.AC-3, PR.AC-5, 
PR.DS-1, PR.DS-6, 

PR.PT-4, DE.CM-1, 
DE.CM-2, DE.DP-4, 
RS.RP-1, RS.CO-2, 

RS.MI-2 


a. The name BIND stands for "Berkeley Internet Name Domain." 
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6 Outcome 


This section discusses the security platform from the perspective of the user and the system 
administrator. We define system administrator as a person within the organization who has 
elevated privileges on the management systems in the build. System administration functions 
include identification of system components, system installation, system integration, system 
configuration, configuration monitoring, identification of exception conditions, system 
maintenance, and status reporting to management. 


6.1 The User’s Experience 

The user's experience varies from relatively minimal additional impact in enterprise 
environments with established system administration and support to a significant impact in the 
case of individual self-supported users. Where the enterprise offers systems administration and 
support services, the user's experience with respect to DNS services is essentially unchanged. 
One exception is that, where DNSSEC authentication fails, email messages sent to or by a user 
will not be delivered. This should be an uncommon experience for correspondents but it is up 
to the enterprise DNS administrator to prevent this happening. 

Similarly, for server-to-server encryption, the security protection features should be essentially 
transparent to the user. 

For user-to-user digital signature, the user must first have a certificate installed in their MUA. 
This may be included in digital identity credentials, or it may be provided by the system 
administrator in the process of provisioning the user's computer. Otherwise, the procedure 
required would be similar to that followed in section 3.2 of SP 1800-6C. The steps required vary 
from platform to platform (e.g., Windows, Linux, Mac), user agent to user agent (e.g., Outlook 
vs Thunderbird) and how the private key is stored (on the system, smart cards, etc.). 
Representative user requirements are described below (in this case for Outlook running on 
MacBook and Thunderbird running on Linux. 

6.1.1 User’s Digital Signature Experience with Outlook on MacBook 

To use digital signatures and encryption, both the sender and recipient must have a mail 
application that supports the S/MIME standard (e.g., Outlook). 

Note: Before this procedure is started, a certificate must be added to the keychain on the 
computer. For information about how to request a digital certificate from a certification authority, 
see MacOS Help or click on “Help” on the Outlook tool bar. 

1. On the Tools menu, click Accounts. 

2. Click the account that is to be used to send a digitally signed message, click Advanced, and 
then click the Security tab. 
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3. Under Digital signing, on the Certificate pop-up menu, click the certificate that is to be 
used. 

Note: The Certificate pop-up menu only displays certificates that are valid for digital signing or 
encryption that have already been added to the keychain for the Mac OS X user account. To 
learn more about how to add certificates to a keychain, see Mac OS Help. 


4. Do any of the following: 


To 

Do this 

Make sure that the digitally signed 
messages can be opened by all 
recipients, even if they do not have an 
S/MIME mail application and can't 
verify the certificate 

Select the Send digitally signed messages as clear 
text check box. 

Allow the recipients to send encrypted 
messages to you 

Make sure that signing and encryption certificates 
have been selected on this screen, and then select 

the Include my certificates in signed messages 

check box. 


5. Click OK, and then close the Accounts dialog box. 

6. In an e-mail message, on the Options tab, click Security, and then click Digitally Sign 
Message. 

7. Finish composing the message, and then click Send. 

6.1.2 User’s Digital Signature Experience with Thunderbird 

For purposes of illustration, the description of the user experience with Thunderbird also 
included certificate management requirements. The example here shows both S/MIME and 
PGP examples of certificate management. The S/MIME approach is recommended. Note that 
when using OpenPGP, a FIPS 140-conformant version should always be used. 

6.1.2.1 S/MIME Certificate Management 

S/MIME certificates are used for digitally signed and encrypted e-mail messages. For 
information about getting or creating S/MIME certificates, see: 

http://kb.mozillazine.org/Getting_an_SMIME_certificate. 


Installing an S/MIME certificate 

Note: Before a user can create or import his or her own certificate and private key he or she 
must first set a master password if this has not already been done. The master password is 
needed so that imported certificates are stored securely. See 

http://kb.mozillazine.org/Master_password for instructions for setting a master password. The 
user may have his or her own personal certificate and private key in a .pi2 or .pfx file, and may 
wish to import it into Thunderbird. Once a Master Password has been set, the user can 
import/install a personal S/MIME certificate from a .pi2 or .pfx file by doing the following steps. 
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1. Open the Certificate Manager by going to Tools -> Options... -> Advanced -> Certificates -> 
Manage Certificates.... 

2. Go to the tab named Your Certificates. 

3. Click on Import. 

4. Select the PCKS12 certificate file (.pfx or .pl2). 

5. It will ask the user for the master password for the software security device. The user enters 
his or her master password and clicks OK. 

6. Next, it will ask the user for the password protecting his or her personal certificate. If the 
user's ,pl2 or .pfx file has a password, he or she enters it here, otherwise leave this field 
empty. Then click OK. 

The S/MIME certificate should now have been imported. If the certificate was not trusted, 
consult the instructions at 

http://kb.mozillazine. 0 rg/Thunderbird_:_FAQs_:_lmport_CA_Certificate. 

Configuring Thunderbird for using the certificate to sign email 

Go to Tools -> Account Settings... in Thunderbird. Then find the account with the email address 
that matches the email address in the certificate that has just been installed. Choose Security 
under that account and select the certificate that has just been installed. The rest of the options 
should be self explanatory. When the user selects a certificate in Account Settings, that 
selection only applies to the account's default identity or identities. There is no user interface 
for specifying certificates for an account's other identities. If desired, this can be worked around 
by editing the settings manually, copying the settings from an account's default identity to 
some other identity. The settings have names ending in: signing_cert_name, sign_mail, 
encryption_cert_name and encryptionpolicy. 

User Installation of a Self-Signed S/MIME Certificate 

If the SMIME certificate in a user's ,pl2 or .pfx file is a self-signed certificate for the user's own 
identity, then before that file can be installed into the tab named Your Certificates, the user 
must first install that certificate as a certificate authority in the Authorities tab. The PKCS12 
certificate file will not install into the Authorities tab. The user will need a copy of a self-signed 
certificate that does not contain the user's private key. This is usually in the form of a .cer file. 
One way to obtain the .cer form of a certificate from the ,pl2 file is to use the Firefox Add-on 
Key Manager to extract the .cer certificate from the ,pl2 file. With that Add-on installed in 
Thunderbird, the user goes to Tools -> Key Manager Toolbox -> Key Manager -> Your Keys, 
select his or her key, selects Export and chooses X.509 as file format. 

1. Go to Tools -> Options... -> Advanced -> Certificates -> Manage Certificates.... 

2. Go to the Authorities tab. 

3. Click on Import. 

4. Select the .cer file. 

5. It will ask the user for what purposes he or she wants to trust the certificate. Select Trust 
this CA to identify email users. 
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6. Click OK to complete the import. 

Note: Thunderbird automatically adds other people's S/MIME certificates to the Other People's 
tab of a user's Certificate Manager when he or she receives from them a digitally signed 
message with a valid signature and with an S/MIME certificate issued by a recognized and 
trusted Certificate Authority (CA). CA certificates that appear in Thunderbird's “Authorities tab 
are recognized, and may also be trusted. CA certificates that do not appear in that tab are 
considered unrecognized. An S/MIME certificate that was issued by an unrecognized CA will 
not be automatically added to the Other People's tab of the user's Certificate Manager. If the 
user attempts to manually import an S/MIME certificate that was issued by an unrecognized CA, 
nothing will happen-literally. Thunderbird will not even display an error dialog. It will just not 
import the S/MIME certificate. This is generally not a problem when receiving an S/MIME 
certificate that was issued by a trusted Certificate Authority (CA), but could be a problem for a 
certificate that was issued by an unrecognized or untrusted CA, or for a certificate that is 
self-signed (i.e. it has no CA other than itself). So, before a user can import an S/MIME 
certificate that is issued by an unrecognized CA or is self-signed, he or she must first acguire 
and import the certificate for the issuing CA. In the case of a self-signed certificate, a .cer file 
needs to be acguired from the individual whose certificate the user wishes to add. 


„9 6.1.2.2 PGP Example of Sending and Receiving Public Keys 


no Sending a public key via email 

, 2 , To send signed messages to other people, the user must first send them the public key: 

,22 1. Compose the message. 

,23 2. Select OpenPGP from the Thunderbird menu bar and select Attach My Public Key. 


124 


Write: (no subject) 

File Edit View Options 
SI Send |j Spelling 



Subject: 


Use PGP/MIME for This Message 

Key Management 

Undo Encryption 

Attach My Public Key 

Help 


3. Send the email as usual. 


,26 Receiving a public key via email 

a? To verify signed messages from other people, the public key must be received and stored: 

us 1. Open the message that contains the public key. 

,29 2. At the bottom of the window, double click on the attachment that ends in .asc. (This file 

no contains the public key.) 
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3. Thunderbird automatically recognizes that this is a PGP key. A dialog box appears, 
prompting the Import or View of the key. Click Import to import the key. 



4. A confirmation that the key has been successfully imported will be shown. Click OK to 
complete the process. 


us Revoking a key 

137 If the private key may have been compromised (that is, someone else has had access to the file 

1 38 that contains the private key), revoke the current set of keys as soon as possible and create a 

139 new pair. To revoke the current set of keys: 

mo 1. On the Thunderbird menu, click OpenPGP and select Key Management. 

File Edit View Go Message [OpenPGP | Jools Help 


£ Get Mail * J Write 

A 

Save Decrypted Message 

ecr 

abhishek...ail.com 



Preferences 


^ Inbox 

Th 

Key Management 

ik 

Drafts 





A Sent 



Help 


Deleted 



Setup Wizard 

— 

mike.ros...ail.com 


E 

About OpenPGP 



, Inbox 


B Drafts ® Read messages 

A Sent 


142 

143 


2. A dialog box appears as shown below. Check Display All Keys by Default to show all the 
keys. 


3. Right-click on the key to be revoked and select Revoke Key. 

4. A dialog box appears asking the user if he or she really wants to revoke the key. The user 
clicks Revoke Key to proceed. 


5. Another dialog box appears asking for the entry of a secret passphrase. The user enters the 
passphrase and clicks OK to revoke the key. 


6 . The user sends the revocation certificate to the people with whom he or she corresponds 
so that they know that the current key is no longer valid. This ensures that if someone tries 
to use the current key to impersonate the user, the recipients will know that the key pair is 
not valid. 
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,53 6.1.2.3 Sending a Digitally Signed Email 

,54 1. Compose the message as usual. 

,55 2. To digitally sign a message, select OpenPGP from the Thunderbird menu and enable the 

,56 Sign Message option. 

Write: (no subject) J 


File Edit View Options 

OpenPGP 1 Teels Help 

PS Send | S Spelling 

V Sign Message Ctrl+Sh’rft+S 

plIME -f B Save 

From: 

Mike 1 

>/ Encrypt Message Ctrl+Shift+E 

)l@gmaiLcom 

To: 

a 

Use PGP/MIME for This Message 




Key Management 




Undo Encryption 




Attach My Public Key 


Subject 


Help 



3. If the email address is associated with a cryptographic certificate, the message will be 
signed with the key contained in that certificate. If the email address is not associated with 
a cryptographic certificate, a certificate must be selected from a list. 

4. Send the message as usual. 


,62 6.1.2.4 Reading a Digitally Signed Email 

,63 When a signed message is received, and If Thunderbird recognizes the signature, a green bar 

,64 (as shown below) appears above the message. To determine whether or not the incoming 

,65 message has been signed, look at the information bar above the message body . 1 

g . p.. 6oods>9niturcfromd||^|^m^^^^9m«Uc<T> » . . 

166 KtyD;0»8Jf92108/S^r(tdc«S,'2& i '2012427PM L * u,s 

,67 If the message has been signed, the green bar also displays the text, "Signed message". A 

,68 message that has not been signed could be from someone trying to impersonate someone else. 


6.2 The System Administrator’s Experience 

The system administrator(s) will generally be responsible for configuring the MUAs, MTA, and 
DNS servers. Specific installation and configuration instructions and examples are provided in 
Sections 2, Section 3, Appendix F, Appendix G, and Appendix H of the How-To Guides, SP 
1800-6C. Configuration includes setting up and publishing certificates in the DNS as TLSA and 
SMIMEA RRs. Certificate management using Well-Known CA-issued certificates or Enterprise 
CA-issued certificates is required for federal government applications and is strongly 
recommended in other applications. While instructions for configuration for DNSSEC are 
provided for environments described in SP 1800-6C, this more secure set of configuration 
options are not generally invoked by default. Therefore, more effort and expertise are needed 
on the part of the DNS administrator. 


1. If the message is also encrypted on a user-to-user basis, Thunderbird will also ask for the entry 
of a secret passphrase to decrypt the message. 
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i bo Configuring and activation of mail servers (MTAs) for channel encryption by default is described 

ib i in section 3.3 of SP 1800-6C. Summary information is provided here and in links for illustration 

iB 2 purposes for Microsoft Office 365 Exchange and Postfix. 

i83 In general, the bulk of the system administrator's effort is in acquiring and publishing the 

iB 4 necessary certificates. Maintenance of the security functions, once they've been set up, is a 

IBs relatively routine system administration activity. 

,bb 6.2.1 Microsoft Exchange 

ib? Only Microsoft Exchange for Office 365 encrypts users' data while it's on Microsoft servers and 

ibb while it's being transmitted between the MTSs. Exchange for Office 365 does provide controls 

189 for end users and administrators to fine tune what kind of encryption is desired to protect files 

1 9 0 and email communications. 


,6.2.2 Postfix 

2 Postfix TLS support is described at http://www.postfix.org/TLS_README.html. Postfix can be 

3 configured to always use TLS when offered by receivers . 2 


2. "Setting Postfix to encrypt all traffic when talking to other mail servers," Snapdragon Tech 
Blog, August 9, 2013. http://blog.snapdragon.cc/2013/07/07/setting-postfix-to-encrypt-all-traf- 
fic-when-talking-to-other-mailservers/ 
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7.1 Assumptions and Limitations.54 

7.2 Testing.54 

7.3 Scenarios and Findings.57 
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.7.1 Assumptions and Limitations 

7 This security characteristic evaluation has the following limitations: 

a ■ It is not a comprehensive test of all security components, nor is it a red team exercise. 

9 ■ It cannot identify all weaknesses. 

10 ■ It does not include the lab infrastructure. It is assumed that its devices are hardened. 

Testing these devices would reveal only weaknesses in implementation that would not be 
i 2 relevant to those adopting this reference architecture. 


J. 2 Testing 

M The evaluation included analysis of the security platforms to identify weaknesses and to discuss 

is mitigations. The focus of this portion of the evaluation was hands-on testing of the laboratory 

I. build and examination of product manuals and documentation. Our objective was to evaluate 

I? the building block and not specific products. The presence of four primary OSs for domains 

is tested (Linux, MacOS, SourceT Micro OS, and Windows) made complete product-independent 

19 hands-on testing unrealistic. 

2 0 Table 7.1 describes the goals of each sequence of test cases. For each sequence, the 

21 Cybersecurity Framework (CSF) Subcategories and associated SP 800-53 control(s), the test 

22 environment(s) involved, and evaluation objective of the test are identified. The results of the 

23 tests are provided NIST SP 1800-6c. 

24 In all test sequences the sending MTA attempted to establish a TLS protected channel to deliver 

25 the email message to the receiver. In the attack scenarios, a malicious actor attempts to disrupt 

26 this transfer. In all test sequences, the sending MUA signed the message, and the receiving 

27 MUA, checked the signature. Exchange was used only for Scenario 2 . 1 In all test sequences, the 

28 sending MTA attempted to verify the correctness of all DNS responses via DNSSEC validation. In 

29 most scenarios, alice@<somedomain> sent an email to bob@<receivername>. Both senders 

30 and receivers had their own (separate) DNS infrastructures consisting of both authoritative and 

31 recursive servers. The Exchange as Sender tests were conducted for completeness and for 

32 examples of SMTP over TLS w/o DANE support - what it looked like and how well it worked. 


1. Exchange MTAs did not attempt to encrypt or decrypt MTA-to-MTA message exchanges. 
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Tests Performed 


Test 

Sequence 


Sequence 1 


CSF 

Subcategories 


PR.AC-1 
PR.AC-2 
PR.DS-1 
PR.DS-2 
PR.DS-6 
RS.MI-2 


SP 800-53 
Controls 


AC-2, AC-17, 

AC-19, 

AC-20, 

IA Family, 
IR-4, SC-8, 
SC-28, SI-7 


Configuration 


An Outlook MUA, interfacing with an Exchange MTA, was 
configured to use Active Directory and BIND DNS services 
in turn. Each of the six configurations exchanged email 
with 

■ a Secure64 MUA/MTA/DNS service stack that included 
a Postfix MTA and a Thunderbird MUA running on a 
Mac OS system 

■ an NLnet Labs MUA/MTA/ DNS service stack that 
included a Postfix MTA and a Thunderbird MUA 
running on Linux 

The events include events showing use of Well-Known 
CAs (CU-1), Enterprise CAs (CU=2), and Self-Signed 
Certificates (CU=3) for TLS and S/MIME-enabled mail 
receivers and S/MIME. Figure 5.2 above depicts the 
set-up for laboratory support for the Secure64 
destination variant of this test sequence. 3 


Evaluation Objective 


Email messages between Postfix MTAs were 
encrypted and successfully decrypted via TLS. 
(Scenario 1). Signature was logged. All 
messages were S/MIME signed. Outlook 
attempted to verify received messages 
(Scenario 2). Signature verification results 
were noted. DNS name verification results 
were noted. 


Sequence 2 


PR.AC-1 
PR.AC-2 
PR.DS-1 
PR.DS-2 
PR.DS-6 
RS.MI-2 


AC-2, AC-17, 

AC-19, 

AC-20, 

IA Family, 
IR-4, SC-8, 
SC-28, SI-7 


Outlook and Thunderbird MUAs, configured to use a 
Postfix MTA with Dovecot IMAP support, were configured 
in turn to use BIND and Secure64's DNS Authority, DNS 
Cache, and DNS Signer implementations. Each of the six 
configurations exchanged email with a Secure64 
MUA/MTA/ DNS service stack that included a Thundebird 
MUA, Postfix/Dovecot MTA, and DNS Signer/DNS 
Cache/DNS Authority services for processing received 
messages; and an NLnet Labs MUA/MTA/ DNS service 
stack that included a Thundebird MUA, Postfix/Dovecot 
MTA, and NSD4, Unbound, and OpenDNSSEC DNS 
services. The test events include using Well-Known CA 
issued (TLSA/SMIMEA CU=1), Enterprise CA issued 
(CU=2), and Self-Signed Certificates (CU=3). Figure 5.2 
above depicts the set-up for laboratory support for this 
test sequence. 


Email messages between MTAs were 
encrypted and successfully decrypted. 
(Scenario 1). Signature and encryption were 
logged. All messages were S/MIME signed. 
Outlook attempted to verify received 
messages (Scenario 2). Signature verification 
results were noted. DNS name verification 
results were noted. 
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Table 7.1 


Tests Performed 


Test 

Sequence 

CSF 

Subcategories 

SP 800-53 
Controls 

Sequence 3 

PR.AC-1 

AC-2, AC-4, 


PR.AC-2 

AC-17, 



AC-19, 


PR.AC-3 

AC-20, 


PR.AC-5 

IA Family, 


PR.DS-2 

IR-4, SC-7, 


RS.MI-1 

SC-8 

Sequence 4 

PR.AC-1 

AC-2, AC-4, 


PR.AC-2 

AC-17, 



AC-19, 


PR.AC-3 

AC-20, 


PR.AC-5 

IA Family, 


PR.DS-2 

IR-4, SC-7, 


PR.DS-6 

SC-8, SI-7 


RS.MI-1 



RS.MI-2 



Configuration 


Fraudulently S/MIME-signed email was sent from a 
malicious sender to recipients using Outlook and 
Thunderbird MUAs configured to use Exchange and 
Postfix as MTAs. The Outlook/Exchange configuration 
used Active Directory as its DNS server. The 
configurations employing Postfix/Dovecot MTAs were 
demonstrated with each of the other three contributed 
DNS Services. In one event, the Thunderbird MUA 
employed an Apple Key Chain Utility tool that allows a 
host to obtain X.509 certificates via of DANE RRs. All 
events were conducted using well-known CA and 
Enterprise CA-issued certificates for the impersonated 
sender. The set-up for this sequence is depicted in 
Figure 5.3 above. 


Evaluation Objective 


The fraudulent site attempted to spoof a valid 
sending domain belonging to a Secure64 site. 
An Outlook/Exchange/ Active Directory set-up 
acted as the fraudulent site. The email 
exchange between organizations was carried 
overTLS, and the email message was S/MIME 
signed on the fraudulent users' client device. 
Where Well-Known CA-issued certificates or 
Enterprise CA-issued certificates were used, 
and the MTA was DANE aware. The MUA 
using a SMIMEA utility was able to detect the 
fraudulent email and mark the email as not 
validated. 


The sender used an Outlook MUA sending mail through a 
Postfix/Dovecot MTA and using (in turn): Active Directory 
and DNS Server, BIND DNS Server, and NLnet Labs DNS 
Services. Self-signed certificates were used on the 
legitimate receiver side (TLSA RR parameter CU=3) for 
TLS. Each of the three configurations attempted to 
initiate an email exchange with an external Secure64 site. 
The set-up for this sequence is depicted in Figure 5.4 
above. 


The man-in-the-middle, an 
Outlook/Exchange/Active Directory stack, 
attempted to intercept the email from the 
NCCoE Laboratory Configuration by acting as 
a Man-in-the-Middle. The email and DNS 
transactions were logged in each case, and 
the results are provided in Volume C Appendix 
C. Where the MTA was DANE-aware, A 
detected spoofing. The mail connection to the 
MTA was established but closed the 
connection before the mail was transferred. 
Otherwise, the MTA failed to detect the 
man-in-the-middle and sent the email. 
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Table 7.1 


Tests Performed 


Test 

Sequence 

CSF 

Subcategories 

SP 800-53 
Controls 

Configuration 

Evaluation Objective 

Sequence 5 

PR.AC-1 

AC-4, IR-5, 

A DANE-enabled Postfix MTA sent message traffic to four 

A large number of email messages are 


PR.DS-6 

SC-5, SC-20, 

MTAs with one Authoritative Server serving all four 

generated in the Postfix server device using a 


PR.CM-1 

SC-21, 

SC-23, SI-4, 

zones. An NSD4 Authoritative DNS server and Unbound 
recursive server were provided for the Postfix sending 

Python script, and the Postfix MTA sends the 
messages to each of four recipient MTAs in 


PR.DP-4 

SI-13 

MTA, and a Secure64 DNS Authority and Signer provided 

different zones. In the recipient MTA running 


PR.CO-2 


the DNS services for the recipient zones. We reviewed 

without TLSA and that running with a valid 



the log files. One of the recipient MTAs did not employ 

matching TLSA and certificate usage field set 




TLSA, one employed a valid TLSA with the CU set to 3, 

to 3, all messages should be accepted. In the 




one employed a TLSA with a certificate usage field of 1, 

recipient MTA with a TLSA RR using certificate 




but with an incomplete (i.e. bad) PKI certification path 

usage of 1, but with an incomplete PKIX 




(PKIX failure), and one employed mismatched server 

validation path, and the recipient MTA with a 




cert/TLSA with the certificate usage field set to 3 (DANE 

mismatched certificate/TLSA (cert usage 3), 




validation failure). 

the sender should close the connection 
without sending the message. Logwatch 
running on the sending Postfix server device 
logged the instances of failure to deliver due 
to certificate expiration or bad certificate 
path. 


a. The connections depicted in the Figure are actually for the Secure64 variant of the first Sequence 2 configuration. Capabilities for Sequence 1 support are shown as dotted lines. 


7.3 Scenarios and Findings 

One aspect of our security evaluation involved assessing how well the reference design addresses the objectives of the scenario it was 
intended to support. 
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Chapter 7. Evaluation 


7.3.1 Scenario 1 

Scenario 1 involved the ordinary exchange of email between two organizations' email servers 
carried over TLS, where the TLS key management was protected by DANE and DNSSEC. Private 
certificates were generated by either well-known CAs, enterprise local CAs or self-signed. User 
connections to their organizations' respective mail servers were established and maintained 
within a physically protected zone, and email was encrypted between mail servers using TLS. 
The confidentiality of encryption keys was maintained such that no unauthorized third party 
had access to the keys. The mail servers used X.509 certificates to store and transport public 
keys to establish the TLS channel. DNSSEC ensured that each sending mail server receives the IP 
address to the legitimate and authorized receiving mail server and (if applicable) validate its 
X.509 certificate. DANE bound the cryptographic keying material to the appropriate server. TLS 
was used to protect the confidentiality of the email exchange. Encryption of the email message 
was accomplished by the originator's email server, and decryption of the email message was 
accomplished by the recipient's email server using standard server libraries. 

The tests included an attempt by a fraudulent mail server to pose as the legitimate mail 
receiver for a domain. The tests also include a man-in-the-middle attack to attempt to disrupt 
the TLS connection with the objective of achieving an unencrypted transmission of the email. 
Both attempts failed due to use of DNSSEC and DANE. In both cases, an indication was made 
available to the sending email server when the DNSSEC signature associated with the domain 
data is determined to be invalid. 


7.3.2 Scenario 2 

Scenario 2 involved end-to-end signed email, where the email exchanges between 
organizations were carried over TLS as in (1), the email messages were signed and verified with 
S/MIME on the end-users' client devices, and the S/MIME key management was protected by 
DANE and DNSSEC. Private certificates were generated by well-known and enterprise local CAs. 
Self-signed certificates were not used. Individuals established connections to their domains' 
respective mail servers within a physically protected zone of control. Cryptographic digital 
signatures were applied to messages to provide authentication and integrity protection for the 
email. S/MIME was the protocol used for the digital signing. These certificates were then 
encoded in the DNS using the appropriate DANE DNS record type. DNSSEC ensured that each 
originating user's mail server connects to the intended recipient's mail server. DANE bound the 
cryptographic keying material to the appropriate server and individual user digital signature 
certificates. TLS was employed to protect the confidentiality of the email. Digital signing of 
email messages was accomplished by originator's MUA, and checking the validity of the 
signature (hence the integrity of the authorization provided in the email message) was 
accomplished by recipient's MUA. 

The tests in this scenario included an attempt by a fraudulent actor to pose as an originator of 
the email. This attempt failed due to use of DNSSEC and DANE. The receiving MUA, using a third 
party SMIMEA tool, was able to fetch the senders real S/MIME certificate from the DNS and 
confirm that the fraudulent email was signed using a different certificate. 
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7.3.3 Effects of DANE Errors 


78 


04 


In addition to the scenarios described above, a DANE-enabled Postfix MTA sent message traffic 
to four other postfix MTAs. A single BIND instance was set up to serve the TLSA and A RRs for 
the four receivers. One of the receiving MTAs did not employ DANE. The second employed 
DANE with a valid TLSA with the certificate usage field 2 set to 3. The third employed a TLSA with 
a certificate usage field of 2, but with an incomplete (i.e. bad) PKI certification path (generating 
a PKIX validation failure). The TLSA contained a local enterprise trust anchor, but the server did 
not have the full certificate chain (missing intermediate certificate). The final one employed 
DANE with a TLSA RR using Certificate Usage of 3, but there was a mismatch between the server 
cert and TLSA RR (generating a DANE validation failure). 

Little or nothing appeared in the sender's logs for messages sent to either the MTA not 
employing TLS or the employing a valid TLSA. The growth rates for logs for the MTA that 
employed a TLSA with a certificate usage field of 1, but with a PKIX failure and the one that 
employed mismatched server cert/TLSA (i.e. DANE validation failure) were measured. 

When the sender was configured to never use TLS, the mail was sent in plaintext regardless of 
the TLS/DANE configuration of the receiver. When the sender was configured to use TLS 
opportunistically, it used TLS regardless of the status of the certificate, or TLSA. In fact, the 
sender did not issue a query to find TLSA RRs even if published. When the sender used 
opportunistic DANE, it used TLS when available regardless of the DANE validations results. If 
validation failed, the mail was still sent and the result was logged as an "Untrusted" or 
"Anonymous" TLS connection, depending on the presence of a TLSA RR. 

Of the four options used in the lab, dane-only is the most rigorous in what a sender would 
accept before sending mail. When the receiver did not offer the STARTTLS option, or lacked a 
TLSA RR, mail was not sent. Likewise, if a TLSA RR was present, but there was an error in 
validation (either the TLSA RR itself had an error, or PKIX failed), the mail was not sent. 
Therefore, use of this option is not recommended for general use as this will result in the 
majority of email being deferred. It should only be used in scenarios where senders and 
receivers are coordinated and maintain a stable DANE deployment. 


2. RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security 
(TLS) Protocol: TLSA, Section 2.1.1. https://tools.ietf.Org/html/rfc6698#section-2.l.l 
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Future Build Considerations 


Both public sector and private sector enterprises are heavily dependent on web-based 
technology other than email for e-commerce and other public-facing applications. Fraudulent 
web sites pose at least as great a security and privacy problem as fraudulent email. Further, as 
email becomes a more difficult medium for malicious entities to use as a penetration vector, 
other web-based media will be more intensively exploited. Already, emerging communications 
trends appear to be replacing email exchanges among individuals with other social media (e.g., 
Baidu, Facebook, Facebook Messenger, Google+, Instagram, Linkedin, Pinterest, Snapchat, 
Tieba, Tumblr, Twitter, Viber, WhatsApp, and YouTube). Therefore, an extension of the current 
project that focuses on use of improved DNSSEC applications such as DANE for web applications 
other than mail may be justified. 

Additionally, the test scenarios did not include the Exchange for Office 365 MTA to demonstrate 
Scenario 1. Future builds might be considered to demonstrate this capability. 

Finally, utilities are currently under development that would provide improved support for 
SMIMEA and improved system notification of failed DNSSEC signature validation events. Future 
builds might be considered to demonstrate these capabilities as well. 
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Acronyms 

3 ASN 

Abstract Syntax Notation 

3 AXFR 

DNS Full Zone Transfer Query Type 

4 BIND 

Berkeley Internet Name Daemon 

s BSD 

Berkeley Software Distribution 

6 CA 

Certificate Authority 

7 CKMS 

Cryptographic Key Management System 

8 CRL 

Certificate Revocation List 

, cu 

Certificate Usage Type 

DANE 

DNS-based Authentication of Named Entities 

„ DNS 

Domain Name System 

u DNSSEC 

DNS Security Extensions 

13 Email 

Electronic Mail 

,4 EMC 

Electromagnetic Compatibility 

,s EMI 

Electromagnetic Interference 

,8 FCKMS 

Federal Cryptographic Key Management System 

,7 FIPS 

Federal Information Processing Standard 

,8 HIPAA 

Health Insurance Portability and Accountability Act 

,9 IEC 

International Electrotechnical Commission 

3o IEEE 

Institute of Electrical and Electronics Engineers 

3, IETF 

Internet Engineering Task Force 

33 IP 

Internet Protocol 

33 IRS 

Internal Revenue Service 

34 ISO 

Internet Organization for Standardization 

35 ITL 

Information Technology Laboratory 

38 MIME 

Multipurpose Internet Mail Extension 

37 MTA 

Mail Transfer Agent 

38 MUA 

Mail User Agent 

3, MX 

Mail Exchange (Resource Record) 

30 NCCoE 

National Cybersecurity Center of Excellence 

3, NIST 

National Institute of Standards and Technology 

33 OS 

Operating System 

33 PKI 

Public Key Infrastructure 
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PKIX 

Public Key Infrastructure X.509 

RFC 

Request for Comments 

RMF 

Risk Management Framework 

RR 

Resource Record 

S/MIME 

Secure/Multipurpose Internet Mail Extensions 

SMIMEA 

S/MIME Certificate Association (Resource Record) 

SMTP 

Simple Mail Transfer Protocol 

SP 

Special Publication 

SQL 

Structured Query Language 

TLS 

Transport Layer Security 

TLSA 

TLS Certificate Association (Resource Record) 

UA 

User Agent 

VLAN 

Virtual Local Area Network 

VM 

Virtual Machine 
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.Appendix C DNS-Based Email Security Project Mapping to the 
Framework Core and Informative References 


The following tables map informative NIST and consensus security references to Framework Core subcategories that are addressed by 
the DNS-Based Email Security platform set. The references do not include protocol specifications that are implemented by the individual 
products that comprise the demonstrated security platforms. While some of the references provide general guidance that informs 
implementation of referenced Framework Core functions, the NIST Special Publication references provide specific recommendations 
that should be considered when composing and configuring security platforms from DNS and email components, implement DNSSEC 
and mail security platforms, and operating email systems securely. 


’Table C.1 PROTECT (PR) 


Category Subcategory Informative References 


PR.AC-1: Identities and 
credentials are managed for 
authorized devices and 
users 

transactions. 


NIST SP 800-45 Ver. 2 3, 6 
NIST SP 800-53 Rev. 4 AC-2, IA Family 
NIST SP 800-57 Part 2 3.1.2.1.3, A.3.2, B.5 
NIST SP 800-81-2 11.7.2 

NIST SP 800-130 2.1, 5, 6.4.2, 6.4.23, 6.5, 6.6.1, 6.6.2, 6.7.1, 8.2.4 
NIST SP 800-152 2.10, 4.8, 4.9.1, 5, 6.4, 6.5, 6.6.1, 6.6.2, 6.7.1, 8.2.3,10.1 
NIST SP 800-177 4.5, 4.6.5, 4.7, 5.1 
CCS CSC 16 

COBIT 5 DSS05.04, DSS06.03 

ISA 62443-2-1:2009 4.3.3.5.1 

ISA 62443-3-3:2013 SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9 
ISO/I EC 27001:2013 A.9.2.1, A.9.2.2, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 


Access Control (PR.AC): Access to assets 
and associated facilities is limited to 
authorized users, processes, or devices, 
and to authorized activities and 
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Table C.1 

PROTECT (PR) 



Category 


Subcategory 

Informative References 




PR.AC-3: Remote access is 
managed 


PR.AC-5: Network integrity 
is protected, incorporating 
network segregation where 
appropriate 


FIPS 140-2 Sec. 4 

NIST SP 800-45 Ver. 2 9.5 

NIST SP 800-53 Rev. 4 AC 17, AC-19, AC-20 

NIST SP 800-57 Part 1 Rev. 4 5.3.1, 6.2.2 

NIST SP 800-81-2 7.2, 9.8, 11.7.5 

NIST SP 800-152 6.7.1, 8.2, 8.3 

NIST SP 800-177 4.4.2.1 

COBIT 5 APO13.01, DSS01.04, DSS05.03 

ISA 62443-2-1:2009 4.3.3.6.6 

ISA 62443-3-3:2013 SR 1.13, SR 2.6 

ISO/I EC 27001:2013 A.6.2.2, A.13.1.1, A.13.2.1 

OMB M-08-23 

NIST SP 800-45 Ver. 2 Rev. 4 8.1.4, 9.5 

NIST SP 800-53 Rev. 4 AC-4, SC-7 

NIST SP 800-81-2 7.2.8, 7.9, 10.4 

NIST SP 800-130 6.8.6 

NIST SP 800-152 6.8.6, 8.3 

NIST SP 800-177 3, 7 

ISA 62443-2-1:2009 4.3.3.4 

ISA 62443-3-3:2013 SR 3.1, SR 3.8 

ISO/I EC 27001:2013 A.13.1.1, A.13.1.3, A.13.2.1 
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Table C.1 PROTECT (PR) 

Category 

Subcategory 

Informative References 

Data Security (PR.DS): Information and 
records (data) are managed consistent 
with the organization's risk strategy to 
protect the confidentiality, integrity, and 
availability of information. 

PR.DS-1: Data-at-rest is 
protected 

FIPS 140-2 Sec. 4 

NIST SP 800-53 Rev. 4 SC-28 

NIST SP 800-57 Part 1 Rev. 4 4.2.5, 5.1.1, 5.2.1, 5.3.4, 5.3.5, 5.3.6, 6.2.2.3 

NIST SP 800-57 Part 2 2.2, 2.4, 3.2, 4.3, 5.3.3, 5.3.4, A.1.2, A.2.1, A.3.2 


NIST SP 800-130 1, 2.1, 2 . 2 , 2 . 9 , 6.1, 6.2, 6.5 

NIST SP 800-152 2.2, 4.3, 4.6, 4.7, 6.1.3, 6.4.14, 6.4.29 

CCS CSC 17 

COBIT 5 AP001.06, BAI02.01, BAI06.01, DSS06.06 
ISA 62443-3-3:2013 SR 3.4, SR 4.1 
ISO/I EC 27001:2013 A.8.2.3 

PR.DS-2: Data-in-transit is FIPS 140-2 Sec. 4 
protected N|ST sp 800 _ 45 Ver 2 All 

NIST SP 800-49 2 


NIST SP 800-52 Rev. 1 3, 4, D1.4 
NIST SP 800-53 Rev. 4 SC-8 


NIST SP 800-57 Part 1 Rev. 4 4.2.5, 5.1.1, 5.2.1, 5.3.4, 5.3.5, 5.3.6, 6.2.1.3 
NIST SP 800-57 Part 2 2.2, 5.3.3, A.2, A.3.1, A.3.2 
NIST SP 800-81-2 All 


NIST SP 800-130 1, 2.1, 2.2, 2.9, 6.1, 6.2, 6.4, 6.7.2 

NIST SP 800-152 6.1.2, 6.2.1 
NIST SP 800-177 All 


CCS CSC 17 


COBIT 5 AP001.06, DSS06.06 

ISA 62443-3-3:2013 SR 3.1, SR 3.8, SR 4.1, SR 4.2 

ISO/I EC 27001:2013 A.8.2.3, A.13.1.1, A.13.2.1, A. 13.2.3, A.14.1.2, A.14.1.3 
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Table C.1 PROTECT (PR) 


Category Subcategory 


PR.DS-6: Integrity checking 
mechanisms are used to 
verify software, firmware, 
and information integrity 


Protective Technology (PR.PT): PR.PT-4: Communications 

Technical security solutions are and control networks are 

managed to ensure the security and protected 

resilience of systems and assets, 

consistent with related policies, 

procedures, and agreements. 


Informative References 


FIPS 140-2 Sec. 4 

NIST SP 800-45 Ver. 2 2.4.2, 3, 4.2.3, 4.3, 5.1, 6.1, 7.2.2, 8.2, 9.2 
NIST SP 800-49 2.2.1, 2.3.2, 3.4 
NIST SP 800-52 Rev. 1 3, 4, D1.4 
NIST SP 800-53 Rev. 4 SI-7 

NIST SP 800-57 Part 1 Rev. 4 5.5, 6.1, 8.1.5.1, B.3.2, B.5 

NIST SP 800-57 Part 2 1, 3.1.2.1.2, 4.1, 4.2, 4.3, A.2.2, A.3.2, C.2.2 

NIST SP 800-81-2 All 

NIST SP 800-130 2.2, 4.3, 6.2.1, 63, 6.4, 6.5, 6.6.1 
NIST SP 800-152 6.1.3, 6.2.1, 8.2.1, 8.2.4, 9.4 
NIST SP 800-177 2.2, 4.1, 4.4, 4,5, 4,7, 5.2, 5.3 
ISA 62443-3-3:2013 SR 3.1, SR 3.3, SR 3.4, SR 3.8 
ISO/I EC 27001:2013 A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3 

OMB M-08-23 

FIPS 140-2 Sec. 4 

NIST SP 800-49 2.4.3, 2.4.4 

NIST SP 800-52 Rev. 13,4 

NIST SP 800-53 Rev. 4 AC-4, AC-17, AC-18, CP-8, SC-7 

NIST SP 800-57 Part 1 Rev. 4 5.3.1, 6.2.2 

NIST SP 800-130 8.3 

NIST SP 800-152 4.7, 4.11.1, 6.8.6, 8.3 

CCS CSC 7 


COBIT 5 DSS05.02, AP013.01 

ISA 62443-3-3:2013 SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 
7.1, SR 7.6 

ISO/I EC 27001:2013 A.13.1.1, A.13.2.1 
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Appendix C. 


,0 Table C.2 DETECT (DE) 


Category 

Subcategory 

Informative References 

Security Continuous Monitoring 

DE.CM-1: The network is 

FIPS 140-2 Sec. 4 

(DE.CM): The information system and 

monitored to detect 

SP 800-37 Rev. 1 3.6 

assets are monitored at discrete 

potential cybersecurity 


intervals to identify cybersecurity 

events 

NIST SP 800-45 Ver. 2 4.1, 5.1.1, 5.1.5, 6.2.1, 6.2.2, 7.2.2 

events and verify the effectiveness of 


NIST SP 800-53 Rev. 4 AC-2, AU-12, CA-7, CM-3, SC-5, SC-7, SI-4 

protective measures. 


NIST SP 800-81-2 2, 9,12,13 

NIST SP 800-130 5, 6.8.5, 8.2.4, 9.8.4 

NIST SP 800-152 6.8.5, 8.2.3, 8.2.4, 8.3, 8.5 

NIST SP 800-177 3.1.1 

CCS CSC 14, 16 

COBIT 5 DSS05.07 

ISA 62443-3-3:2013 SR 6.2 


DE.CM-6: External service 

NIST SP 800-53 Rev. 4 CA-7, PS-7, SA-4, SA-9, SI-4 


provider activity is 
monitored to detect 

NIST SP 800-81-2 2, 9,12,13 


potential cybersecurity 

NIST SP 800-130 6.8.5, 8.2.4, 9.8.4, 12 


events 

NIST SP 800-152 6.8.5, 8.2.3, 8.2.4, 8.3, 8.5 

ISO/IEC 27001:2013 A.14.2.7, A. 15.2.1 

Detection Process (DE.DP): Detection 

DE.DP-4: Event detection 

NIST SP 800-45 Ver. 2 9.3 

processes and procedures are 

information is 

NIST SP 800-53 Rev. 4 AU-6, CA-2, CA-7, RA-5, SI-4 

maintained and tested to ensure timely 

communicated to 


and adequate awareness of anomalous 

appropriate parties 

NIST SP 800-177 4.6 

events. 


COBIT 5 APO12.06 

ISA 62443-2-1:2009 4.3.4.5.9 

ISA 62443-3-3:2013 SR 6.1 

ISO/IEC 27001:2013 A.16.1.2 
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" Table C.3 RESPOND (RS) 
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Appendix C. 


Table C.3 RESPOND (RS) 


Category 

Subcategory 

Informative References 

Mitigation (RS.MI): Activities are 

RS.MI-1: Incidents are 

NIST SP 800-53 Rev. 4 IR-4 

performed to prevent expansion of an 
event, mitigate its effects, and eradicate 

contained 

NIST SP 800-130 6.8.1 

the incident. 


NIST SP 800-152 6.8 

ISA 62443-2-1:2009 4.3.4.5.6 

ISA 62443-3-3:2013 SR 5.1, SR 5.2, SR 5.4 

ISO/IEC 27001:2013 A.16.1.5 


RS.MI-2: Incidents are 

NIST SP 800-53 Rev. 4 IR-4 


mitigated 

NIST SP 800-57 Part 1 Rev. 4 5.3, 5.4, 5.5, 8.3.4, 8.3.5 

NIST SP 800-57 Part 2 5.3.7, 5.3.8 

NIST SP 800-130 4.9.3, 6.8, 9.5, 12 

NIST SP 800-152 3.4.2, 4.5, 6.8, 9.5, 9.8, 12 

ISA 62443-2-1:2009 4.3.4.5.6, 4.3.4.5.10 

ISO/IEC 27001:2013 A.12.2.1, A.16.1.5 
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The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards 
and Technology (NIST) addresses businesses' most pressing cybersecurity problems with 
practical, standards-based solutions using commercially available technologies. The NCCoE 
collaborates with industry, academic, and government experts to build modular, open, end-to- 
end reference designs that are broadly applicable and repeatable. The center's work results in 
publicly available NIST Cybersecurity Practice Guides, Special Publication Series 1800, that 
provide users with the materials lists, configuration files, and other information they need to 
adopt a similar approach. 

To learn more about the NCCoE, visit http://nccoe.nist.gov. To learn more about NIST, visit 

http://www.nist.gov. 

NIST CYBERSECURITY PRACTICE GUIDES 

NIST Cybersecurity Practice Guides (Special Publication Series 1800) target specific cybersecurity 
challenges in the public and private sectors. They are practical, user-friendly guides that 
facilitate the adoption of standards-based approaches to cybersecurity. They show members of 
the information security community how to implement example solutions that help them align 
more easily with relevant standards and best practices. 

The documents in this series describe example implementations of cybersecurity practices that 
businesses and other organizations may voluntarily adopt. The documents in this series do not 
describe regulations or mandatory practices, nor do they carry statutory authority. 

ABSTRACT 

This document proposes a reference guide on how to architect, install, and configure a security 
platform for trustworthy email exchanges across organizational boundaries. The project includes 
reliable authentication of mail servers, digitally signing and encrypting email, and binding 
cryptographic key certificates to sources and servers. The example solutions and architectures 
presented here are based upon standards-based and commercially available products. The 
example solutions presented here can be used by any organization implementing Domain Name 
System-based electronic mail security. 
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Chapter 1. Introduction 


6 The following guide shows IT professionals and security engineers how we implemented 

7 example solutions to the challenge of employing Domain Name System Security Extensions 

8 (DNSSEC) 1 , and protocol-based digital signature and encryption technologies to protect 

9 electronic mail (email). We cover all the products that we employed in our solution set. We do 

10 not recreate the product manufacturer's documentation, which is presumed to be widely 

11 available. Rather, this guide shows how we incorporated the products together in our 

12 environment to provide composed security platforms. 

13 Note: This is not a comprehensive tutorial. There are many possible service and security 

14 configurations for these products that are out of scope for this reference solution set. 


is 1.1 Practice Guide Structure 


16 This National Institute of Standards and Technology (NIST) Cybersecurity Practice Guide 

17 addresses the challenge of providing digital signature technologies to provide authentication 

18 and integrity protection for electronic mail (email) on an end-to-end basis, and confidentiality 

19 protection for email in transit between organizations. 


20 The NIST Special Publication 1800-6 series of documents contain: 


21 

22 

23 


rationale for and descriptions of a Domain Name System-Based (DNS-Based) Electronic Mail 
(Email) Security platform that permits trustworthy email exchanges across organizational 
boundaries 


24 

25 

26 


a series of How-To Guides, including instructions for installation and configuration of the 
necessary services, that show system administrators and security engineers how to achieve 
similar outcomes 


27 The solutions and architectures presented are built upon standards-based, commercially 

28 available products. These solutions can be used by any organization deploying email services 

29 that is willing to implement certificate-based cryptographic key management and DNS Security 

30 Extensions (DNSSEC). Interoperable solutions are provided that are available from different 

31 types of sources (e.g., both commercial and open source products) and function in different 

32 operating systems environments. 

33 This summary section describes the challenge addressed by this Volume C (How-To Guide) the 

34 solution demonstrated to address the challenge, the components provided by project 

35 collaborators that have been used to compose the security platforms, an overview of how the 

36 components are configured to permit construction of platforms that cross product lines, and 

37 typographical conventions used in the Practice Guide. Section 2, How to Install and Configure 

38 DNS-Protected Email Security Components, provides mail and transport layer security 

39 composition and component-centric requirements and recommendations intended to permit 

40 using Mail User Agent (MUA) 2 , Mail Transfer Agent (MTA) 3 , and DNS Services components with 
MUAs, MTAs, and DNS Services from different vendors and open sources. It includes system 
requirements, installation instructions and advice and special settings requirements associated 


1. RFC 4033, DNS Security Introduction and Requirements 

2. According to NIST Special Publication (SP) 800-177, a MUA is a software component (or web 

interface) that allows an end user to compose and send messages and to one or more recipients. 
A MUA transmits new messages to a server for further processing (either final delivery or trans¬ 
fer to another server). See Section 2, Definitions, at https://tools.ietf.org/html/rfc3888. 
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43 with each of the MUA, MTA, and DNS Services components. In most cases where the 

components are commercial products, links are simply provided to vendor sites. More detailed 

45 instructions are provided for downloading, installing, and configuring open-source products. 

46 Section 3, Device Configuration and Operating Recommendations, provides some specific 

47 advice and tools to support secure ands reliable integration and operation of the security 

48 platforms. Topics include certificate acquisition and management options, managing mail 

49 transfer agent operation where there are significant numbers of cases of non-delivery of 

50 messages due to invalid digital signatures, device setup recommendations, email setup 

51 recommendations, and management of exception conditions. Appendix A is a list of Acronyms. 

52 Appendix B provides references. Appendix C describes test events and results from exercising 

53 different combinations of components into composed security platforms, including system 

54 responses to attempts to subvert DNSSEC protection mechanisms. Appendix D is a checklist for 

55 recommended secure domain name system deployment practices. Finally, for readers 

56 unfamiliar with any of the specific components employed by this project, Appendix E provides a 

57 set of high-level collaborator product descriptions for contributed components. Appendix F 

58 describes an example NCCoE installation and configuration of components provided by our 

59 NLnet Labs collaborator. Appendix G describes an example NCCoE installation and configuration 

60 of components provided by our Microsoft collaborator. Appendix H describes NCCoE 

61 installation and configuration of components provided by our Secure64 collaborator. 


62 1.2 Build Overview 


63 1.2.1 Usage Scenarios Supported 

64 The scenarios supported include: 

65 ■ "ordinary" email where the email exchanges between two organizations' email servers 

66 communicate over Transport Layer Security (TLS) 1 with a STARTTLS 2 extension, and relevant 

67 TLSA 3 records are published in the receiver's DNS zone protected by DNSSEC (Scenario 1 in 

68 this document) 

69 ■ end-to-end signed email, where the email exchanges between users in different 

70 organizations are carried over a channel protected by TLS (using the STARTTLS extension), 

71 and relevant artifacts used for signing and channel protection are published in a DNS zone 

72 protected by DNSSEC (Scenario 2). Subsequently, these artifacts are used for 

73 Secure/Multipurpose Internet Mail Extensions (S/MIME) 4 and TLS validation. 


3. Also according to SP 800-177, mail is transmitted, in a "store and forward" fashion, across net¬ 
works via Mail Transfer Agents (MTAs). MTAs communicate using the Simple Mail Transfer Pro¬ 
tocol (SMTP) described below and act as both client and server, depending on the situation. See 
Section 2, Definitions, at https://tools.ietf.org/html/rfc3888. 

1. RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2 

2. See RFC 3207, SMTP Service Extension for Secure SMTP over Transport Layer Security. 

3. RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security 
(TLS) Protocol: TLSA, Proposed Standard (August 2012; Errata) Updated by RFC 7671, RFC 7218 

4. RFC 2633, S/MIME Version 3 Message Specification 
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74 In both scenarios, end-entity and personal certificates were generated from Certificate 

75 Authorities (CAs) 1 . Use of "well known" (i.e. installed as trust anchors in hosts), local enterprise 

76 CAs and self-signed certificates were demonstrated. 

77 While the second scenario demonstrated signing of emails, it does not include an end-to-end 

78 encrypted email scenario. Signing addresses the main security concerns in enterprise 

79 environments, which are the target of the project, but may neglect concerns of individual users 

so who may also want to reduce information disclosure to their email providers. The two 

81 scenarios that are included may, however, serve as enablers for end-to-end encryption. 

82 Participation by parties having a primarily end-to-end encryption focus may succeed in 

83 generating industry support for the building blocks needed to support end-to-end encryption. 

84 In more detail, the project's security platforms use the STARTTLS extension to include 

85 encryption of communications between two MTAs, as well as the signature of individual 

86 messages using S/MIME. The encryption and decryption with S/MIME on the end user's client 

87 was excluded from the current platform demonstration. 


ss 1.2.2 Architectural Overview 

89 The laboratory architecture for the DNSSEC-Based Email Security project was designed to 

90 permit interconnection of Microsoft Outlook, Apple Mail, and Thunderbird MUAs with 

91 Microsoft Exchange and Postfix/Dovecot MTAs. It demonstrates the interconnection of either 

92 MTA with various DNS services contributed by collaborators. Two instantiations of each MTA 

93 type were established to demonstrate email exchanges between MTAs of the same type or 

94 different types. The various component combinations were demonstrated with three different 

95 TLSA RR 2 parameters: a self-signed certificate, use of local certificate authorities, and use of 

96 well-known certificate authorities. 

97 Figure 1.1 is a deployment diagram of the architecture used for demonstrating DNS-Based 

98 Email Security. 

99 The following subsections describe the architecture's MUA, MTA, and DNS service components 

100 and Cybersecurity Framework Core categories supported by those components. Component 

descriptions are provided in Appendix E for those not familiar with some of the individual 

102 components. 


1. According to NISTSP 800-177, a trusted Certificate Authority (CA) is licensed to validate appli¬ 
cants' credentials, store their public key in a X.509 [RFC5280] structure, and digitally sign it with 
the CA's private key. TLS relies on public key cryptography and uses X.509 certificates [RFC5280] 
to encapsulate the public key, and the CA system to issue certificates and authenticate the origin 
of the key. An organization can generate its own root certificate and give its members a certifi¬ 
cate generated from that root, or purchase certificates for each member from a well-known CA. 

2. According to RFC 6698, The TLSA DNS resource record (RR) is used to associate a TLS server 
certificate or public key with the domain name where the record is found, thus forming a "TLSA 
certificate association". 
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103 1.2.2.1 Client Systems and Mail User Agents (MUAs) 

Client systems environments demonstrated were Microsoft Office, an open-source Linux-based 

105 Thunderbird application, and Thunderbird with a Secure 64 -provided Apple Key Chain utility. 

106 This set includes both commercial products and open-source software. MUA capabilities 

107 associated with the client systems are used to invoke S/MIME digital signature and signature 

108 verification for email, but user-to-user encryption is not demonstrated. Collaborators assisted 

109 in installation, integration tailoring as necessary, and testing of laboratory configurations. 


no 1.2.2.2 Email Servers 


in 

112 

113 

114 

115 

116 
117 


Email servers include both Windows and Linux-based (Postfix/Dovecot) Mail Transfer Agents. 
Server-to-server encryption was demonstrated in Postfix environments. Authentication of 
domain and server identity was based on DNSSEC-signed DANE records. Use of these DANE 
records is only supported by Postfix at the time of this project. The servers were demonstrated 
in different DNS environments and different TLSA RR usage scenarios. In order to demonstrate 
representative TLSA parameters, the demonstrations used self-signed certificates, end-entity 
certificates generated by well-known CAs and end-entities generated by enterprise local CAs. 


ns Figure 1.1 DNS-Based Email Security Deployment Diagram 




119 
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120 1.2.2.3 DNS Servers 

Both Windows and Linux-based DNS server and support components were contributed. DNS 
services provided include DNSSEC validating DNS resolvers (stub and recursive) and 
123 authoritative DNS servers for DNSSEC signed zones. 1 Support for SMIMEA and TLSA records was 

demonstrated. DNS components included Microsoft's Active Directory and DNS Server; Internet 

125 Systems Consortium's (ISC's) Berkeley Internet Name Domain (BIND); NLnet Labs' NSD 4 , 

126 Unbound, and OpenDNSSEC; and Secure 64 's DNS Signer, DNS Authority, DNS Cache, DNS 

127 Manager, and Apple Key Chain Utility. 


i 28 1.3 Typographical Conventions 

129 The following table presents typographic conventions used in this volume. 

130 _ 


Typeface/ Symbol 

Meaning 

Example 

Italics 

filenames and pathnames 

references to documents that are 
not hyperlinks, new terms, and 
placeholders 

For detailed definitions of terms, seethe 
NCCoE Glossary. 

Bold 

names of menus, options, 
command buttons and fields 

Choose File > Edit. 

Monospace 

command-line input, on-screen 
computer output, sample code 
examples, status codes 

mkdir 

Monospace Bold 

command-line user input 
contrasted with computer output 

service sshd start 

blue text 

link to other parts of the 
document, a web URL, or an email 
address 

All publications from NIST's National 
Cybersecurity Center of Excellence are 
available at http://nccoe.nist.gov 


1. https://www.ietf.org/rfc/rfcl034.txt 
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Chapter 2. How to Install and Configure DNS-Protected Email Security Components 


16 This section explains set up for the component sets provided by project collaborators. Set-up is 

17 described for a virtual machine environment. The environment used for this project was the 

18 Centos 7 Linux distribution running on VMware. This section includes a description of the 

19 laboratory set-up for the capability demonstrations and flow charts for installation and 

20 configuration of mail security and DNS security components in an enterprise. This configuration 
overview is followed by some general instructions for installation and configuration of open 
source components are provided, with links to source sites for more detailed instructions. Less 

23 general installation is provided for commercial components, but links are provided to the 

vendor sites. Specific installation and configuration instructions for the NCCoE environment are 

25 provided as appendices (Appendix F, Appendix G, and Appendix H). 


26 2.1 Laboratory Set-up 

27 The design of the environment permits interconnection of components provided by different 

28 collaborators (see figure 2 . 1 ). 

29 The depiction shows that the project security platform test/demonstration activity was based 

30 on three different clients, two MTAs, and four DNS service configurations in the lab at the 

31 NCCoE exchanging messages with NLnet Labs and Secure 64 . All messages were signed (a mail 

32 client function). Messages sent via a Postfix MTA were encrypted (server to server). The 

33 message exchanges, including DNS activity will be logged at each end (lab and remote 

34 correspondent). 

35 The solid connectors in the depiction illustrate one case. The dotted lines depict the other cases 

36 we'll want to demonstrate. A switch convention is used to reflect configuration options, but the 

37 project team actually configures each component for each option. 

38 The orange arrows between the mail clients and the Postfix MTA reflect the fact that clients 

39 submitted email directly to the SMTP server for relay, while using Dovecot only to get mail. (The 

40 depiction in figure 2.1 reflects that IMAP isn't used to submit mail, only retrieve it, so the MUA 
sent mail directly to the Postfix server, but received the reply through the Dovecot server.) 
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42 


Figure 2.1 DNS-Based Email Security Test Set-up 


43 



. Mail & DNS Information 


The project team demonstrated 30 different events using various combinations of MUA, MTA, and DNS Server components divided 

45 among five test sequences. In each sequence, signed and encrypted messages were sent from a sender to a recipient. Postfix encrypted 

46 mail by default. Most of the exchanges employed either self-signed certificates or local CAs (see Appendix C). The BIND configuration 

47 was set up to obtain and validate certificates from the NIST Advanced Networks Technology Division's (ANTD's) DNS source (acting as a 

48 root CA). 
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49 2.1.1 Sequence 1 Set-up 


50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

Table 2.1 


Sequence 1 demonstrated use of well-known CA issued cryptographic certificates (CU= 1 ), 
enterprise CA issued certificates (CU= 2 ), and self-signed certificates (CU= 3 ) with an 
Outlook/Exchange/Active Directory and Outlook/Exchange/BIND MUA/MTA/DNS Server stack. 1 
Mail was exchanged between the NCCoE and two remote sites. The first site, Secure 64 in Ft 
Collins, Colorado, used a Thunderbird MUA with a utility for MacBook that can fetch SMIMEA 
records and put them into a key store, a Postfix MTA, and Signer/Authority/Cache DNS servers. 
The NLnet site used an Intel-hosted Thunderbird MUA, a Postfix/Dovecot MTA, NSD 4 and 
Unbound for processing received messages, and OpenDNSSEC for outbound messages. All 
messages were S/MIME signed (Scenario 2 only). 

Test Sequence 1 


Sequence 

1 


NCCoE Lab 

Remote Sites 

Certificate on 

Event 

MUA 

MTA 

DNS Service 

Secure64 and NLnet Labs 


1 

Outlook 

Exchange 

Active Directory 
/DNS Server 

Enterprise CA issued (CU=2) 

Well-known CA issued 
(CU=1) 

2 

Outlook 

Exchange 

Active Directory 
/DNS Server 

Same as 1 

Local CA issued 
(CU=2) 

3 

Outlook 

Exchange 

Active Directory 
/DNS Server 

Same as 1 

Self-Signed Cert 
(CU=3) 

4 

Outlook 

Exchange 

BIND 

Same as 1 

Well-known CA issued 
(CU=1) 

5 

Outlook 

Exchange 

BIND 

Same as 1 

Local CA issued 
(CU=2) 

6 

Outlook 

Exchange 

BIND 

Same as 1 

Self-Cert (CU=3) 


6o2.1.2 Sequence 2 Set-up 

61 Sequence 2 demonstrated use of an Outlook/Postfix MUA/MTA configuration with a BIND DNS 

62 Server, and a Thunderbird/Postfix MUA/MTA configuration with both BIND and DNS 

63 Signer/Authority/Cache set-ups. All three certificate usage approaches were demonstrated. 

64 Mail was exchanged between the NCCoE and both Secure 64 and NLnet Labs sites. As in 

65 Sequence 1 , the secure 64 site used a Thunderbird MUA, a Postfix MTA, and 

66 OpenDNSSEC/Unbound/NSD 4 DNS servers; and the NLnet Labs site used a Thunderbird MUA, a 


1. The integrity of cryptographic certificates is generally checked by verifying a digital signature 
generated for the certificate by its source. Certificates may be self-signed by an entity that both 
generates and uses it, signed by the parent enterprise that is responsible for generating and us¬ 
ing the certificate, or be signed by some "well-known" third party certificate source that is trust¬ 
ed by organizations using the certificates for cryptographic protection processes. Certificate 
usage is designated "CU=1" for certificates issued by well-known CAs, "CU=2" for certificates is¬ 
sued by enterprise CAs (also known as Local CAs), and "CU=3" for certificates that are self-signed. 
CU=1 is generally considered most trustworthy, and CU=3 is considered least trustworthy. 
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67 Postfix/Dovecot MTA, NSD 4 and Unbound for DNS processing received messages, and 

68 OpenDNSSEC for outbound messages. Email messages between MTAs were encrypted and 

69 successfully decrypted via TLS; an intermediate processor verified that encryption occurred; 

70 inspection of the received message verified that decryption was successful; 

71 encryption/decryption results were noted; and all messages were S/MIME signed (Scenarios 1 

72 and 2 ). 

73 

Table 2.2 Test Sequence 2 


Sequence 

2 


NCCoE Lab 

Remote Sites 

Certificate 
on Receiver 

Event 

MUA 

MTA 

DNS Service 

Secure64 and NLnet Labs 

Side 

7 

Outlook 

Postfix/ 

Dovecot 

BIND 

Thunderbird, Postfix/ Dovecot, 
NSD4/Unbound/ Open DNSSEC 

Self-Signed Cert (CU=3) 

Well-known 

CA issued 
(CU=1) 

8 

Thunderbird 

Postfix/ 

Dovecot 

BIND 

Same as 7 

Local CA 
issued (CU=2) 

9 

Thunderbird 

Postfix/ 

Dovecot 

BIND 

Same as 7 

Self-Signed 

Cert (CU=3) 

10 

Thunderbird 

Postfix/ 

Dovecot 

DNS Authority/ 
Cache/ Signer 

Same as 7 

Well-known 

CA issued 
(CU=1) 

11 

Thunderbird 

Postfix/ 

Dovecot 

DNS Authority/ 
Cache/ Signer 

Same as 7 

Local CA 
issued (CU=2) 

12 

Thunderbird 

Postfix/ 

Dovecot 

DNS Authority/ 
Cache/ Signer 

Same as 7 

Self-Cert 

(CU=3) 


742.1.3 Sequence 3 Set-up 

75 Sequence 3 used an Outlook/Exchange/Active Directory stack to pose as the remote suite used 

76 in Sequence 1 and attempt to spoof an Outlook/Exchange Active Directory stack and a 

77 Thunderbird/Postfix configuration served by each of three DNS server types 

78 (OpenDNSSEC/NSD 4 /Unbound, DNS Signer/Authority/Cache, and BIND). All events were 

79 conducted using well-known CA and Enterprise CA-issued certificates for the impersonated 

80 sender. The email exchange between organizations was carried over TLS, and the email 

81 message was S/MIME signed on the fraudulent users' client device. 
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82 

" Table 2.3 Test Sequence 3 


Sequence 

3 


NCCoE Lab 

Remote Sites 

Certificate 
on Receiver 

Event 

MUA 

MTA 

DNS Service 

Secure64 and NLnet Labs 

Side 

13 

Outlook 

Exchange 

Active Directory 

Thunderbird on MacBook, 
Postfix/Dovecot, DNS 

Authority/ Cache/Signer Local 

CA issued (CU=2) 

Local CA 
(CU=1) 

14 

Thunderbird 

Postfix/ 

Dovecot 

NSD4/ 

Unbound/ 

OpenDNSSEC 

Same as 13 

Local CA 
issued (CU=1) 

15 

Thunderbird 

on MacBook 

Postfix/ 

Dovecot 

DNS Authority/ 
Cache/Signer 

Same as 13 

Local CA 
issued (CU=1) 

16 

Outlook 

Exchange 

Active Directory 

Same as 13 

Self-Signed 

Cert (CU=3) 

17 

Thunderbird 

Postfix/ 

Dovecot 

NSD4/Unbound/ 
Open DNSSEC 

Same as 13 

Self-Signed 

Cert (CU=3) 

18 

Thunderbird 

Postfix/ 

Dovecot 

BIND 

Same as 13 

Self-Cert 

(CU=3) 


832.1.4 Sequence 4 Set-up 


84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

Table 2.4 


Attempts were made to send a TLS protected email from Exchange and Postfix MTAs (in turn) to 
an external Postfix MTA using DNS Authority/Cache/Signer for DNS services. The NCCoE 
Exchange MTA used Active Directory DNS Services, and the Postfix/Dovecot MTA uses BIND, 
NSD 4 /Unbound/OpenDNSSEC, and DNS Signer/Authority/Cache DNS services. An S/MIME 
signed email was sent to an external Postfix MTA. Events were conducted using Well-Known CA 
issued certificates, events using Enterprise CA issued certificates (TLSA/SMIMEA RR parameter 
of CU= 2 ) for TLS and S/MIME on the receiver side, and three using self-signed certificates 
(TLSA/SMIMEA RR parameter of CU= 3 ) for TLS and S/MIME on the receiver side. An 
Outlook/Exchange/Active Directory stack acted as a man-in-the-middle and attempted to 
impersonate the legitimate receiver. 

Test Sequence 4 


Sequence 

3 


NCCoE Lab 

Legitimate Remote Site 

Certificate 
on Receiver 

Event 

MUA 

MTA 

DNS Service 


Side 

19 

Outlook 

Exchange 

Active Directory 

Secure64 

Well-Known 

CA (CU=1) 

20 

Thunderbird 

Exchange 

BIND 

Secure64 

Well-Known 

CA (CU=1) 

21 

Thunderbird 

Postfix 

NSD4/Unbound/ 
Open DNSSEC 

Secure64 

Well-Known 

CA (CU=1) 
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Table 2.4 Test Sequence 4 


Sequence 

3 


NCCoE Lab 

Legitimate Remote Site 

Certificate 
on Receiver 

Event 

MUA 

MTA 

DNS Service 


Side 

22 

Thunderbird 

on MacBook 

Postfix/ 

Dovecot 

DNS Authority/ 
Cache/Signer 

Secure64 

Well-Known 

CA (CU=1) 

23 

Outlook 

Exchange 

Active Directory 

Secure64 

Local CA 
(CU=2) 

24 

Thunderbird 

Postfix/ 

Dovecot 

BIND 

Secure64 

Local CA 
(CU=2) 

25 

Thunderbird 

on MacBook 

Postfix/ 

Dovecot 

NSD4/Unbound/ 
Open DNSSEC 

Secure64 

Local CA 
(CU=2) 

26 

Thunderbird 

on MacBook 

Postfix/ 

Dovecot 

DNS Authority/ 
Cache/Signer 

Secure64 

Local CA 
(CU=2) 

27 

Thunderbird 

Postfix/ 

Dovecot 

Active Directory 

Secure64 

Self-Cert 

(CU=3) 

28 

Thunderbird 

Exchange 

BIND 

Secure64 

Self-Cert 

(CU=3) 

29 

Thunderbird 

on MacBook 

Postfix/ 

Dovecot 

NSD4/Unbound/ 
Open DNSSEC 

Secure64 

Self-Cert 

(CU=3) 


95 2.1.5 Sequence 5 Set-up 

96 This sequence used an Authoritative DNS Server, a DANE-aware Postfix server, and four 

97 Exchange MTAs (each set up differently). One ran without TLSA, one had good TLSA and a 

98 self-signed certificate (CU= 3 ), one had bad PKIX and a certificate from a well-known CA (CU= 1 ), 

99 and one had a bad TLSA with a self-signed certificate (CU= 3 ). A script running on the Postfix 

100 server generates a message stream. Logs of failed DNS events were examined. 


101 2.1.6 How to Deploy SMIMEA and TLSA Software for Trustworthy Email 

Set-up for the test sequences required deploying SMIMEA and TLSA, and adding certificates and 

103 records for users. Figures 3 and 4 are flowcharts depicting the steps required for installation 

104 and configuration of MUAs, MTAs, and DNS servers necessary to trustworthy email. Figure 2.2 

105 depicts the process for setting up secure/multipurpose Internet mail extensions (S/MIME and 

106 SMIMEA). Figure 2.3 depicts the process for setting up transport layer security (i.e., TLS and 

107 TLSA). The figures assume that the enterprise has deployed DNSSEC, including DANE-aware 

108 components. The figures include questions regarding the installation and configuration status 

109 of components, and provides recommendations based on the answers to those questions. 
Together with the Secure Name System (DNS) Deployment Checklist provided as Appendix D, 
these flowcharts are intended to facilitate establishment of a trustworthy email capability in a 

ii2 wide range of environments. 
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113 Figure 2.2 S/MIME and SMIMEA Deployment Flowchart 
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115 Figure 2.3 TLS/TLSA Deployment Flowchart 


116 



ii 7 2.1.7 Adding and Removing Network Users 

ns Adding users to networks with trustworthy email enabled involves identity management 

ii9 administrative, DNS administrative, and end user support activities. Figure 2.4 depicts the 

process for generating user network identities, new S/MIME Certificates for users, and SMIMEA 
resource records; publishing the records in the DNS, and configuring users' MUAs to use 
122 S/MIME keys. 
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123 Figure 2.4 Adding Network Users for Trustworthy Email 


ID Management Admin 


H- 


Desktop 
Support or 
End User 


-H 



H- 


■H 


DNS Admin 


124 

When a user leaves an organization or access to network resources is revoked for other reasons, 

126 it is necessary to revoke the credentials that associate the user with the organization. This 

127 action requires the network or system administrator to disable the user's network ID, revoke 

128 the user's S/MIME certificates, and archive the certificates and associated keys; and requires 

129 the DNS administrator to remove the user's SMIMEA resource records (RRs). Figure 2.5 depicts 

130 the flow for this process. 

131 Figure 2.5 Removing Network Users for Trustworthy Email 


Network/System Admin 



132 
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133 2.2 

How to Install and Configure Microsoft Server-Based 

134 

DNS-Protected Email Security Components 

135 

136 

137 

138 

139 

140 

141 

142 

143 

Outlook, Exchange, Active Directory, and DNS Server are commercial products that can be 
accessed from Microsoft's web (e.g., https://www.microsoft.com/en-us/). Outlook is generally 
bundled in Microsoft Office (e.g., Office365 for Windows 10), and DNS Server is bundled in 
Microsoft Server systems (e.g., Server 2016). Active Directory tools and applications are not 
installed in Windows 10 by default, but instructions regarding how to get them can be found at 
http://www.technipages.com/windows-install-active-directory-users-and-computers. DNS 
Server is bundled with Server 2016. Please note that IP addresses, domain names, and mail 
addresses are, in many cases, specific to the NCCoE laboratory configuration and must not be 
used in actual implementations. 

1442.2.1 

Installation Basics and System Requirements 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

System requirements are product-specific, and installation instructions are highly dependent of 
version, intended configuration, and tools set employed. The installation process, tools 
employed, and configuration process followed in setting up the NCCoE Microsoft components 
are provided as Appendix G to this Practice Guide. Manual pages are provided for individual 
applications of products and tools (e.g., 

https://technet.microsoft.com/en-us/library/bb245702(v=exchg.80).aspx and 
https://technet.microsoft.com/en-us/library/bbl23543(v=exchg.l41).aspx for Exchange, 
https://technet.microsoft.com/en-us/library/dn626158(v=exchg.l50).aspx for Outlook), and 
https://technet.microsoft.com/en-us/library/cc732284(v=ws.ll).aspx for configuring a DNS 
server for use with Active Directory domain services; and from a wide variety of third party 

sources. 

1562.2.2 

Installation of Active Directory, Server, and Exchange in the NCCoE 

157 

Configuration 

158 

159 

Appendix G describes installation and configuration of Active Directory, Server, and Exchange at 
the NCCoE. 

16o2.3 

How to Install and Configure BIND 1 

161 

162 

163 

164 

165 

166 

167 

168 

The current guide for getting started with BIND and instruction on how to build and run named 
with a basic recursive configuration can be found at 

https://kb.isc.org/article/AA-00768/46/Getting-started-with-BIND-how-to-build-and-run-nam 
ed-with-a-basic-recursive-configuration.html. The current BIND 9 Reference Manual can be 
found at https://www.isc.org/wp-content/uploads/2014/01/Bv910ARM.pdf&hl=en_US. An 

overview of installation and configuration basics follow. Please note that IP addresses, domain 
names, and mail addresses are, in many cases, specific to the NCCoE laboratory configuration 
and must not be used in actual implementations. 
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169 2.3.1 Installation Basics and System Requirements 

no The NCCoE BIND installation was based on Centos 7. ISC specifies that BIND 9 currently requires 

171 a UNIX system with an ANSI C compiler, basic POSIX support, and a 64 bit integer type. 

172 ISC has also had success in building and testing on the following systems: 

173 ■ COMPAQ Tru64 UNIX 5.IB 

174 ■ Fedora Core 6 

175 ■ FreeBSD 4.10, 5.2.1, 6.2 

176 ■ HP-UX 11.11 

177 ■ Mac OS X 10.5 

178 ■ NetBSD 3.x, 4.0-beta, 5.0-beta 

179 ■ OpenBSD 3.3 and up 

iso ■ Solaris 8, 9, 9 (x86), 10 

181 ■ Ubuntu 7.04, 7.10 

182 ■ Windows XP/2003/2008 

183 ISC also has recent reports from the user community that a supported version of BIND will build 

184 and run on the following systems: 

185 ■ AIX4.3,5L 

186 ■ CentOS 4, 4.5, 5 

187 ■ Darwin 9.0.0dl/ARM 

188 ■ Debian 4, 5, 6 

189 ■ Fedora Core 5, 7, 8 

190 ■ FreeBSD 6, 7, 8 

191 ■ HP-UX 11.23 PA 

192 ■ MacOSX 10.5, 10.6, 10.7 

193 ■ Red Hat Enterprise Linux 4, 5, 6 

194 ■ SCO OpenServer 5.0.6 

195 ■ Slackware 9,10 

196 ■ SuSE 9, 10 


197 Note: As of BIND 9.5.1, 9.4.3, and 9.3.6, older versions of Windows, including Windows NT and 

198 Windows 2000, are no longer supported. 


1. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit 
(http://www.openssl.org/), cryptographic software written by Eric Young (eay@cryptsoft.com), and soft¬ 
ware written by Tim Fludson (tjh@cryptsoft.com). 


DNS-Based Email Security Practice Guide 


19 







Chapter 2. How to Install and Configure DNS-Protected Email Security Components 


199 Information regarding downloading BIND can be found at 

200 https://www.isc.org/downloads/bind/ 


201 2.3.2 BIND Installation and Configuration 

202 ISC's recommended link for BIND starter information is: 

203 https://kb.isc.org/article/AA-00768/46/Getting-started-with-BIND-how-to-build-and-run-nam 

204 ed-with-a-basic-recursive-configuration.html. For authoritative configuration, refer to the 

205 BIND9 ARM (https://www.isc.org/downloads/bind/doc/bind-9-10/). 

206 To build, just enter: 

207 . /configure 

208 make 

209 Do not use a parallel "make". 


210 2.3.2.1 Environmental Variables 

Several BIND environment variables that can be set before running configure will affect 

212 compilation: 

213 ■ CC 

The C compiler to use. configure tries to figure out the right one for supported systems. 

215 ■ CFLAGS 


216 

217 

218 

219 

220 

221 

222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 


C compiler flags. Defaults to include -g and/or -02 as supported by the compiler. Please 
include '-g' if you need to set CFLAGS. 

■ STD_CINCLUDES 

System header file directories. Can be used to specify where add-on thread or IPv6 support 
is, for example. STD_CINCLUDES defaults to empty string. 

■ STD_CDEFINES 

Any additional preprocessor symbols you want defined. STD_CDEFINES defaults to empty 
string. 

Possible settings: 

• Change the default syslog facility of named/lwresd. 

- DIS C_FAC ILITY=LOG_LOCAL 0 

• Enable DNSSEC signature chasing support in dig. 

-DDIG_SIGCHASE=1 (sets -DDIG_SIGCHASE_TD=1 and 
-DDIG_SIGCHASE_BU=1) 

• Disable dropping queries from particular well known ports. 

-DNS_CLIENT_DROPPORT=0 

• Sibling glue checking in named-checkzone is enabled by default. 
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233 

234 

235 

236 

237 

238 

239 

240 

241 

242 


To disable the default check set. -dcheck_sibling=0. 

• named-checkzone checks out-of-zone addresses by default. 

To disable this default set -dcheck_local=0. 

• To create the default pid files in $ { localstatedir} /run rather than 

${localstatedir}/run/{named,lwresd} /set -DNS RUN PID DIR=0 

• Enable workaround for Solaris kernel bug about /dev/poll 

-DISC_SOCKET_USE_POLLWATCH=l 

• The watch timeout is also configurable, e.g., 

-DISC_SOCKET_POLLWATCH_TIMEOUT=20 

LDFLAGS 


243 


Linker flags. Defaults to empty string. 


244 2.3.2.2 

245 

246 

247 

248 

249 

250 

251 

252 

253 


Cross Compiling 

The following need to be set when cross compiling: 

■ BUILD_CC 

The native C compiler. 

■ BUILD_CFLAGS (optional) 

■ BUILD_CPPFLAGS (optional) 

Possible Settings: 

-dneed_optarg=1 (optarg is not declared in <unistd.h>). 

■ BUILD_LDFLAGS (optional) 

■ BUILDJJBS (optional) 


254 2.3.2.3 Multithreading Support 

255 On most platforms, BIND 9 is built with multithreading support, allowing it to take advantage of 

256 multiple CPUs. You can configure this by specifying --enable-threads or --disable-threads 

257 on the configure command line. The default is to enable threads, except on some older 

258 operating systems on which threads are known to have had problems in the past. 

259 Note: Prior to BIND 9.10, the default was to disable threads on Linux systems; this has been 

260 reversed. On Linux systems, the threaded build is known to change BIND's behavior with 

26 1 respect to file permissions; it may be necessary to specify a user with the -u option when running 

262 named. 


263 2.3.2.4 Shared Libraries 

264 To build shared libraries, specify --with-libtool on the configure command line. 
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265 2.3.2.5 Large Servers 


266 

267 

268 

269 

270 


Certain BIND compiled-in constants and default settings can be increased to values better 
suited to large servers with abundant memory resources (e.g, 64-bit servers with 12G or more 
of memory) by specifying —with-tuning=iarge on the configure command line. This can 
improve performance on big servers, but will consume more memory and may degrade 
performance on smaller systems. 


27i 2.3.2.6 DNSSEC Support 


272 

273 

274 

275 


For the BIND server to support DNSSEC, you need to build it with crypto support. You must have 
OpenSSL 0.9.5a or newer installed and specify — with-openssi on the configure command 
line. If OpenSSL is installed under a nonstandard prefix, you can tell configure where to look for 
it using --with-openssl=/prefix. 


2762.3.2.7 

277 

278 

279 

280 
281 


HTTP Statistics Channel Support 

To support the HTTP statistics channel, the BIND server must be linked with at least one of the 
following: Iibxml2 (http://xmlsoft.org) or json-c (https://github.com/json-c). If these are 
installed at a nonstandard prefix, use — with-iibxmi2=/prefix or —with-iibjson=/prefix. 

To support compression on the HTTP statistics channel, the server must be linked against libzlib 

(--with-zlib=/prefix). 


282 2.3.2.8 Python Support 

283 Python requires 'argparse' and 'ply' to be available, 'argparse' is a standard module as of 

284 Python 2.7 and Python 3.2. 


285 2.3.2.9 Files Larger than 2GB 

286 On some platforms it is necessary to explicitly request large file support to handle files bigger 

287 than 2GB. This can be done by —enabie-iargefile on the BIND configure command line. 


2882.3.2.10 Fixed rrset-order Option 


289 Support for the fixed rrset-order option can be enabled or disabled by specifying 

290 — enable-fixed-rrset or —disable-fixed-rrset on the BIND configure command line. The 

291 default is disabled, to reduce memory footprint. 


2922.3.2.1 1 IPv6 Support 

293 If your operating system has integrated support for IPv6, it will be used automatically. If you 

294 have installed KAME IPv6 separately, use — with-kame[=PATH] to specify its location. 


295 2.3.2.12 Installing named and BIND 9 Libraries 

296 The make install tool will install named and the various BIND 9 libraries. By default, installation 

297 is into /usr/local, but this can be changed with the -prefix option when running configure. 
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298 2.3.2.13 Directory Setting Options 


299 

300 

301 

302 

303 


You may specify the option — sysconfdir to set the directory where configuration files like 
named, conf go by default, and --locaistatedir to set the default parent directory of 
run/named.pid. For backwards compatibility with BIND 8, —sysconfdir defaults to /etc and 
—locaistatedir defaults to /var if no -prefix option is given. If there is a -prefix option, 
sysconfdir defaults to $prefix/etC and locaistatedir defaults to $prefix/var. 


304 2.3.2.14 Other Configure Options 


305 

306 

307 

308 


To see additional configure options, run configure —help. Note that the help message does 
not reflect the BIND 8 compatibility defaults for sysconfdir and locaistatedir. If you're 
planning on making changes to the BIND 9 source, you should also make depend. If you're using 
Emacs, you might find make tags helpful. 


309 2.3.2.15 Re-running Configure 

If you need to re-run configure please run make distclean first. This will ensure that all the 
3ii option changes take. 


312 2.3.2.16 Building with gcc 

313 Building with gcc is not supported, unless gcc is the vendor's usual compiler (e.g. the various 

314 BSD systems, Linux). 


315 2.3.2.17 

316 

317 

318 

319 

320 

321 

322 

323 


Known Compiler and OS Issues 

Known compiler issues include the following: 

■ gcc-3.2.1 and gcc-3.1.1 is known to cause problems with solaris-x86. 

■ gcc prior to gcc-3.2.3 ultrasparc generates incorrect code at -02. 

■ gcc-3.3.5 powerpc generates incorrect code at -02. 

■ Irix, MipsPRO 7.4.1m is known to cause problems. 

■ SunOS 4 requires printf to be installed to make the shared libraries. 

■ sh-utils-1. 16 provides a printf which compiles on SunOS 4. 

■ Linux requires kernel 


3242.3.3 Testing 

325 A limited BIND test suite can be run with make test. Many of the tests require you to configure 

326 a set of virtual IP addresses on your system, and some require Perl. (See 

327 bin/tests/system/README for details). 


3282.3.4 BIND Documentation 

329 The BIND 9 Administrator Reference Manual is included with the source distribution in 

330 DocBook XML and HTML format, in the doc/arm directory. 
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331 Some of the programs in the BIND 9 distribution have man pages in their directories. In 

332 particular, the command line options of named are documented in /bin/named/named.8. 

333 There is now also a set of man pages for the Iwres library. 

334 For upgrading from BIND 8, please read the migration notes in doc/misc/migration. If you are 

335 upgrading from BIND 4, read doc/misc/migration-4to9. 

336 Frequently asked questions and their answers can be found in FAQ. 

337 Additional information on various subjects can be found in the other README files. 


3382.3.5 BIND Support 

339 Although BIND is open source software, support is available from ISC. 


3 4 o 2.4 NSD 4 Requirements, Installation, Setup, and 

34 1 Configuration Components 

342 The links for NSD 4.1.13 tar files, manual pages, and SVN repository can be found at 

343 https://www.nlnetlabs.nl/projects/nsd/. This repository provides for downloading of the latest 

344 NSD 4 version. NSD 4 can be installed on Unix-based systems (e.g., FreeBSD, OpenBSD, NetBSD, 

345 Mac OS X, and Solaris), including Linux systems such as Red Hat Enterprise, Centos, Debian, 

346 Ubuntu, and Gentoo. Please note that IP addresses, domain names, and mail addresses are, in 

347 many cases, specific to the NCCoE laboratory configuration and must not be used in actual 

348 implementations. 


3492.4.1 NSD 4 Installation Basics 


350 

351 

352 

353 

354 

355 

356 

357 


NSD4 is available in distribution repositories such that a package manager can install it with a 
single command: 

For Red Hat Enterprise and Centos (Centos 7 was used in the NCCoE example): 

yum install nsd 

For Debian and Ubuntu: 

sudo apt-get install nsd 

For Gentoo: 

emerge nsd 


3582 .4.2 NSD 4 Configuration (nsd.conf) 

359 Different paths exist for NSD4 (nsd.conf). Their paths depend on your distribution: 

360 Centos - Red Hat Enterprise: /etc/nsd/nsd. conf 

361 Debian - Ubuntu: /etc/nsd/nsd.conf 
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3622.4.2.1 

363 

364 

365 

366 

367 

368 

369 

370 

371 

372 

373 

374 

375 

376 

377 

378 

379 

380 

381 

382 

383 

384 

385 

386 

387 

388 

389 

390 

391 

392 

393 

394 

395 

396 

397 

398 

399 

400 

401 

402 

403 

404 


Master Configuration 

The following is a master configuration for NSD4 for a Centos system. This example shows nsd4 
serving the domain dnslabs.dnsops.gov on the IP address 129.6.45.38. The log file for the actual 
NCCoE installation and configuration of NSD4 with Unbound and OpenDNSSEC for the 
DNS-Based Email Security project is provided as Appendix F. 

# 

# nsd.conf -- the NSD(8) configuration file, nsd.conf(5). 

# 

# Copyright (c) 2001-2011, NLnet Labs. All rights reserved. 

# 

# See LICENSE for the license. 

# 

# This is a configuration file commented out, you just need to change 
the IP and the zone file to customize it. 

# options for the nsd server 
server: 

# uncomment to specify specific interfaces to 
bind (default wildcard interface). 

# ip-address: localhost 
ip-address: 129.6.45.38 

# don't answer VERSION.BIND and VERSION.SERVER 
CHAOS class queries 

# Keep yes for security reasons, 
hide-version: yes 

# enable debug mode, does not fork daemon process into the background. 

# debug-mode: no 

# do-ip4 
default: yes 

# do-ip6 
default: yes 

# Enable IPv6 as advice. 

# the database to use, this is the standard path. 

# disable database mode. Explicitly set database: "" 

# database: "" 
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405 

406 

407 

408 

409 

410 

411 

412 

413 

414 

415 

416 

417 

418 

419 

420 

421 
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423 

424 

425 

426 
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429 

430 

431 

432 

433 

434 

435 

436 

437 

438 

439 

440 

441 

442 

443 

444 

445 

446 

447 


# identify the server (CH TXT ID.SERVER entry). 
identity: "" 

# NSID identity (hex string). default disabled. 

# nsid: "aabbccdd" 

# log messages to file. Default to stderr and 
syslog (with facility LOG_DAEMON). 

# logfile: "/var/log/nsd.log" 

# Number of NSD servers to fork, keep 1 for low 
memory VPS 

server-count: 1 

# Maximum number of concurrent TCP connections 
per server. 

# This option should have a value below 1000, 10 
is good for a low memory VPS 

tcp-count: 10 

# Maximum number of queries served on a single 
TCP connection. 

# By default 0, which means no maximum. 

# tcp-query-count: 0 

# Override the default (120 seconds) TCP timeout. 

# tcp-timeout: 120 

# Preferred EDNS buffer size for IPv4. 

# ipv4-edns-size: 4096 

# Preferred EDNS buffer size for IPv6. 

# ipv6-edns-size: 4096 

# File to store pid for nsd in. 

# pidfile: "/var/run/nsd/nsd.pid" 

# port to answer queries on. default is 53. 

# port: 53 

# statistics are produced every number of 
seconds. 

# statistics: 3600 
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448 

449 # if per zone statistics is enabled, file to 

450 store statistics. 

451 # zone-stats-f ile : "/var/log/nsd. stats" 

452 

453 # The directory for zonefile: files. 

454 zonesdir: "/etc/nsd/zones" 

455 

456 #This is the definition of the first zone, you 

457 must have 1 for every domain. 

458 zone: 

459 name: dnslabs.dnsops.gov 

460 #file in the zonesdir that contains the domain 

461 information. 

462 zonefile: dnslabs . dnsops . gov. conf 

463 

464 # See https://www.nlnetlabs.n1/projects/nsd/nsd-control.8.html for 

465 nsd-control config 


4662.4.2.2 NSD Zone File 


467 The next step is setting up zone files. The following instructions set up a simple zone file that 

468 just defines the SOA, the NS, MX and some address for the domain: 

469 ;## NSD authoritative only DNS 

470 

471 $ORIGIN dnslabs.dnsops.gov. ; default zone domain 

472 $TTL 86400 ; default time to live 

473 

474 @ IN SOA nevl admin@dnslabs.dnsops.gov ( 

475 2 0 1 2 0 8 2 7 0 3 ; serial number 

476 2 8 8 0 0 ; Refresh 

477 1 4 4 0 0 ; Retry 

478 8 6 4 0 0 0 ; Expire 

479 8 6 4 0 0 ; Min TTL 

480 ) 

481 

482 NS nevl.dnslabs.dnsops.gov . 

483 NS nev2.dnslabs.dnsops.gov . 

484 MX 10 mail.dnslabs.dnsops.gov . 

485 

486 mail IN A 129.6.45.38 

487 www IN A 129.6.45.38 

488 nevl IN A 129.6.45.38 

489 nev2 IN A 129.6.45.38 
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490 

491 

492 

493 

494 

495 

496 

497 
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502 

503 2.4.2.3 

504 
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508 

509 

510 

511 

512 

513 

514 

515 2.4.2.4 

516 

517 

518 

519 

520 

521 

522 

523 

524 

525 


* IN A 129.6.45.38 
@ IN A 129.6.45.38 

;## NSD authoritative only DNS 

For NSD it is a requisite to set your NS name server hostname (nevl.dnslabs.dnsops.gov to 
129.6.45.38 in this example) to the same IP address NSD is listening on, the one we have set in 
the nsd.conf file. This is so important because a resolving DNS server, like BIND, will ask NSD 
what the current authoritative name server IP address is. NSD will say the name server for 

dnslabs . dnsops . gov is nevl. dnslabs . dnsops . gov and its IP is 129.6.45.38. And so 
129.6.45.38 is the address that another service like BIND will use to connect. 

* IN A 129.6.45.38 

includes the names in the domain . dnslabs . dnsops . gov. 

Compile the NSD Database and Start Daemon 

Note: NLnet Labs advises against running NSD4 in the database mode unless there is a 
compelling local reason. 

1. General 

Nsd-control stop/start 

2. Restart Command: If a message is received that there are errors in the zone file, correct 
them; otherwise restart as follows: 

a. For Red Hat or Centos Server: 

/etc/init.d/nsd restart 

b. For Debian or Ubuntu server: 

/etc/init.d/nsd4 restart 

Note: A restart is not needed to reload zonefile. Use reload or reconfig. 

Testing NSD4 

The easiest way to test the NSD4 configuration is to run a dig from the resolver querying the 
NSD server for the domain you just defined, such as: 

dig @129.6.45.38 dnslabs.dnsops.gov 

The output should look something like the following: 

; &lt;&lt;&gt;&gt ; DIG 9.3.6-20.PI.el5_8.2 ; 

&lt;&lt;&gt;&gt; @129.6.45.38 dnslabs.dnsops.gov 
; 1(1 server found) 

;; global options: printcmd 
;; Got answer: 

;; -&gt;&gt;HEADER&lt; 
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526 

527 

528 


In this output you should see in the answer section the correct association between your DNS 
name and IP, and in the AUTHORITY section the correct association between your NS and the 
configured IP. 


529 

530 

531 


2.4.2.5 NSD4 Support 


Although NSD4 is open source software, support is available from NLnet Labs via its subsidiary 
Open Netlabs (http://www.opennetlabs.com). 


5322.5 How to Install and Configure OpenDNSSEC 

533 The log file for an actual NCCoE installation and configuration of OpenDNSSEC with Unbound 

534 and NSD4 for the DNS-Based Email Security project is provided as Appendix F. For cryptographic 

535 operations, OpenDNSSEC uses the PKCS#11 interface supported by hardware security modules 

536 (HSMs). As an alternative to real HSMs, the OpenDNSSEC project developed SoftHSM, a drop-in 

537 replacement that uses the Botan or OpenSSL cryptographic library. SQLite or MySQL can be 

538 used as database back-ends. It is used on the .se, .dk, .nl, .ca, and .uk top-level domains and 

539 more. OpenDNSSEC can be downloaded from: 

540 ■ https://dist.opendnssec.Org/source/opendnssec-2.0.l.tar.gz 

541 ■ https://dist.opendnssec.Org/source/opendnssec-2.0.l.tar.gz.sig 

542 ■ Checksum SHA256: 

543 bf874bbb346699a5b539699f90a54e0cl5fff0574df7a3cll8abb30938b7b346 

544 Please note that IP addresses, domain names, and mail addresses are, in many cases, specific to 

545 the NCCoE laboratory configuration and must not be used in actual implementations. 


5462.5.1 OpenDNSSEC Installation Basics and System Requirements 

547 OpenDNSSEC 1 will run on most Linux, BSD and Solaris operating systems. The community 

548 provides binary packages for several platforms to assist installation. This Practice Guide, 

549 however, assumes those packages are not available. If you have found an appropriate system to 

550 run OpenDNSSEC on, it is time to install its dependencies. OpenDNSSEC relies on a database 

551 backend and currently supports MySQL and SQLite. MySQL is recommended because SQLite 

552 doesn't scale well and has some known locking issues. Furthermore, OpenDNSSEC depends on: 

553 ■ Idns, version 1.6.12 and up with the exceptions of 1.6.14 and 1.6.15 

554 ■ Iibxml2, Iibxml2-dev, Iibxml2 

555 As indicated above, OpenDNSSEC generally assumes use of a cryptographic Hardware Security 

556 Module (HSM) via the PKCSffll interface. An alternative is use of SoftHSM, a software-only 

557 implementation of an HSM. SoftHSM depends on Botan (a cryptographic library) version 1.8.5 

558 or greater, or OpenSSL (for SoftHSM 2.0 and higher), and SQLite version 3.3.9 or greater. Install 

559 SoftHSM (https://www.opendnssec.org/2016/03/softhsm-2-l-0/) with: 


560 


$ tar -xzf softhsm-X.Y.Z.tar.gz 


1. https://www.opendnssec.org/. 
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561 $ cd softhsm-X. Y. Z $ ./configure 

562 $ make 

563 $ sudo make install 

564 By default, the binary will be installed in /usr/local/bin/ and the configuration is expected 

565 to be at /etc/softhsm. conf . Open the file and specify a slot for OpenDNSSEC. For example: 

566 # SoftHSM slots 0 :/var/lib/sof thsm/slotO . db 

567 The token database does not exist at this stage. It is necessary to initialize it with: 

568 $ softhsm --init-token --slot 0 --label "OpenDNSSEC" 

569 When prompted, fill in a SO (Security Officer) PIN and user PIN. Remember it, you will need to 

570 configure it for OpenDNSSEC. The SO PIN can be used to reinitialize the token. The user PIN is 

571 handed out to OpenDNSSEC. If your company does not have a SO, just pick the same PIN for 

572 both roles. 

573 Make sure OpenDNSSEC has permission to access the token database. 

574 $ chown opendnssec /var/lib/softhsm/slotO.db 

575 $ chgrp opendnssec /var/lib/softhsm/slotO.db 


5762.5.2 OpenDNSSEC Installation 


577 
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583 

584 
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587 


While the log file for an actual installation and configuration of OpenDNSSEC with Unbound and 
NSD4 for the DNS-Based Email Security project is provided as Appendix F, some more general 
information regarding OpenDNSSEC installation 1 follows: 

Run these commands to install OpenDNSSEC: 

$ tar -xzf opendnssec-X.Y.Z.tar.gz 
$ cd OpenDNSSEC-X.Y.Z $ ./configure 
$ make 

$ make install 

By default, the binaries will be installed in /usr/local/bin/ and /usr/local/sbin/. The 
configuration files are located in the /etc/opendnssec/ directory. The working directories are 
under /var/opendnssec/. 


58s 2.5.3 OpenDNSSEC Configuration Requirements 


589 

590 

591 

592 

593 


The default configuration installs default values for entities that just wants to sign their domains 
with DNSSEC. There are four configuration files for the basic OpenDNSSEC installation: 

■ conf.xml which is the overall configuration of the system 

■ kasp.xml which contains the policy of signing 

■ zonelist.xml where you list all the zones that you are going to sign 


1. The NLnet Labs OpenDNSSEC team provided most of the text in this section. This text is also 
available in an expanded form on OpenDNSSEC Wiki https://wiki.opendnssec.org/dis- 

play/DOCS20/OpenDNSSEC. 
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■ addns.xml (per zone, optional) for zone transfers 

For now, it is necessary to edit conf.xml only because we need to configure the cryptographic 
security module must be configured (e.g., an HSM or software module such as SoftHSM or 
SoftHSM 2 .x). Make the Repository part look like: 

<Repository name="SoftHSM"> 

<Module>/usr/local/lib/libsofthsm.so</Module> 
<TokenLabel>OpenDNSSEC</TokenLabel> 

<PIN>XXXX</PIN> 

<SkipPublicKey/> 

</Repository> 

Here, XXXX is the user PIN entered in section 2.4.1 above. 

OpenDNSSECs Key and Signing Policy (KASP) provides standard values for signing any zone. 
However, if an organization chooses to change any value, it is possible to add a new policy, or 
change values in an existing policy. For example, if a zone uses the YYYYMMDDXX format for 

SOA SERIAL values, change the Serial parameter in kasp.xml from unixtime to datecounter: 

<Zone> 

<PropagationDelay>PT9999S</PropagationDelay> 

<SOA> 

<TTL>PT3600S</TTL> 

<Minimum>PT3600S</Minimum> 

<Serial>datecounter</Serial> 

</SOA> 

</Zone> 

For full descriptions about all the KASP parameters, see the OpenDNSSEC Wiki 1 . 


6182.5.4 Running OpenDNSSEC 

619 When starting OpenDNSSEC for the first time, it is first necessary to setup the database. There 

620 is a control script that starts up two daemons: ods-enforcerd that takes care of the key 

621 management, and ods-signerd that is the actual signer. 

622 Run: 

623 $ ods-enforcer-db-setup 

624 *WARNING* This will erase all data in the database; are you sure? [y/n] 

625 y 

626 $ ods-control start 

627 At this point, OpenDNSSEC is running. Logs are going to syslog. The setup has imported the two 

628 default Key And Signing Policies (KASP), default and lab. However, no zones are imported yet. 


1 . OpenDNSSEC Documentation: https://wiki.opendnssec.org/display/DOCS 20 /kasp.xml. 
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6292.5.5 Adding Zones 

630 Until the zone list zonelist.xml is edited, OpenDNSSEC starts with no zones to sign. It is 

631 necessary to add zones (and remove zones as necessary). One way to add a zone is to enter the 

632 following command: 

633 $ ods-enforcer zone add -z example.com 

634 This adds the zone example.com to OpenDNSSEC with the default KASP. Also by default, the 

635 signing is file based. Note that the enforcer doesn't read this file without being told explicitly to 

636 do so. Also, the file will not be written when adding new zones via commandline. 

637 The signer expects the unsigned file to be at /var/opendnssec/unsigned/example. com 

638 and puts the signed file at /var/opendnssec/signed/example . com. Different paths can be 

639 used with -i (input) and -o (output). You can use a different policy with -p (policy). 

640 If a user or administrator wants to use DNS zone transfers for input and output, the type of 

641 adapter can be set to DNS, - j for input and -q for output. It is necessary to set the input and 

642 output files to the zone transfer configuration file addns.xml, like this: 

643 $ ods-ksmutil zone add -z example.com -j DNS -q DNS \ 

644 -i /etc/opendnssec/addns.xml -o /etc/opendnssec/addns.xml 

645 Instructions on how to edit addns.xml for zone transfers is described in section 2.5.5.1 below. 

646 The signed zone is then written in the /var/opendnssec/signed/ directory. It is necessary 

647 to notify your name server of the new zonefile in order for the zone to also become visible in 

648 the DNS. It is possible to configure a notify command in conf.xml to automatically notify the 

649 name server of new zones. For example: 

650 <Conf iguration> 

651 ... 

652 <Signer> 

653 ... 

654 <NotifyCommand>nameserver_control_program reload 

655 %zone</Notif yCommand> 

656 </Signer> 

657 </Conf iguration> 

658 Here, %zone will be replaced with the name of the zone that has been updated, and %zonefile 

659 (not used in example) will be replaced with the name of the signed zonefile. 


66o2.5.5.1 OpenDNSSEC as a Bump-in-the-Wire 

661 If a zone has been added with DNS adapters rather than working on files, instead of pointing 

662 the input and output to the filenames of the unsigned and signed zones, it is necessary to put in 

663 the zone transfer configuration file addns.xml. Here, primary name server addresses, ports and 

664 TSIG keys (Inbound), and ports and TSIG keys for the secondary name servers (Outbound) are 

665 set up. Replace the example values in addns.xml.sample installed in /etc/opendnssec/ with 

666 the desired servers and keys and rename it to addns.xml. Also conf.xml needs a socket that 

667 listens to DNS traffic: 

668 <Conf iguration> 

669 ... 
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<Signer> 


<Listener> 

<Interface><Address>127.0.0.l</Address><Port>53</Portx/Interface> 
<Interface><Address>: : l</AddressXPort>53</PortX/Interface> 
<Listener> 

</Signer> 

</Configuration> 

The above values are also the defaults. OpenDNSSEC can now sign incoming zone transfers (full 
and incremental) and also reply to SOA, AXFR and IXFR requests. 

Activating Key Signing Keys (KSK) 

At this stage, an attempt to list OpenDNSSEC keys will reveal that the key signing key (KSK) is not 
yet active: 

$ ods-enforcer key list -a 

Zone: Keytype: State: Date of next transition: 

example.com. KSK publish 2016-09-01 00:00:01 example.com. ZSK active 
2016-08-31 10:00:01 

This is because the DS must still be submitted to the parent. The DS is a record that is derived 
from the KSK and is published in the parent zone. This is used to build a secure chain of trust 
from the root zone to the users zone. In the example above, OpenDNSSEC expects this to 
happen at one second past midnight on the first of September 2016 . This is 14 hours after initial 
signing. This is because the default policy has a very conservative propagation delay for the 
name servers: 12 hours. In this example, it takes an additional hour for the TTL and one more 
for the publish safety parameter - totaling 14 hours Enduring the long propagation delay is 
necessary because, in order to make sure a zone remains valid, it is necessary to respect a 
publish safety duration and the TTL (in this case derived from the SOA MINIMUM). If 
OpenDNSSEC is ready, the date of next transition be displayed as waiting for ds-seen. The DS 
can then be submitted to the parent. How that is accomplished depends on your organization's 
registrar. Usually this can be done via e-mail or through a web interface. Retrieve the DNSKEY or 
DS with: 

$ ods-enforcer key export 

;ready KSK DNSKEY record: example.com. 3600 IN DNSKEY 257 3 8 Aw... 

$ ods-enforcer key export -d 

;ready KSK DS record (SHA1): example.com.. 3600 IN DS 42112 8 1 8aea... 

;ready KSK DS record (SHA256): example.com. 3600 IN DS 42112 8 2 
a67 4 . . . 

If the DS shows up in the parent zone at all parent name servers, it is safe to run the key 
ds-seen command. This command requires the keytag of the key in question. You can see from 
the DNSKEY and DS records this is 42112 in this example: 

$ ods-enforcer key ds-seen -z example.com -x 42112 

The KSK is now also active, and the chain-of-trust is set up. 
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CD 

c\i 

Unbound 
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713 
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719 

The log file for an actual NCCoE installation and configuration of Unbound with NSD4 and 
OpenDNSSEC for the DNS-Based Email Security project is provided as Appendix F. The latest 
version of unbound (currently 1.5.10) can always be downloaded from 

http://www.unbound.net/downloads/unbound-latest.tar.gz. 1 Unbound documentation can be 
found at https://unbound.net/documentation/index.html. Some general installation and 
configuration information for Unbound is provided in the following subsections. Please note 
that IP addresses, domain names, and mail addresses are, in many cases, specific to the NCCoE 
laboratory configuration and must not be used in actual implementations. 

720 2 .6. 1 

Unbound Installation Basics and System Requirements 

721 

722 

723 

724 

725 

726 

727 

728 

729 

730 

If your distribution package manager includes a package for Unbound install the package with 
the package manager. If not, in order to compile the software it is necessary to have openssl, 
and its include files (from a package often called openssl-devel). In openssl, run ./configure 
[options]; make; and make install. For cases in which the libldns library is not installed, a 
version is included with the Unbound source tarball and is automatically used. Unbound always 
uses sldns (the included Idns). With respect to options for configure, the default config 
locations for various files and directories can be customized, as well as the install location for 
the program with --prefix=/usr/local. You can specify — with-iibevent=dir or 
—with-ssl=dir to link with the library at that location. In general, no options are needed for 
./configure. 

731 

On some BSD systems it is necessary to use gmake instead of make. 

732 

733 

734 

It is possible to install with make install and to uninstall with make uninstall. The uninstall 
does not remove the config file. In the contrib directory in the unbound source are sample rc.d 
scripts for unbound (for BSD and Linux type systems). 

735 2.6.2 

Unbound Setup and Installation 

736 

737 

738 

739 

740 

741 

The config file is copied into /usr/local/etc/unbound/unbound. conf but some 
distributions may put it in /etc/unbound/unbound .conf or /etc/unbound .conf. The 

config file is fully annotated, you can go through it and select the options you like. Or you can 
use the below, a quick set of common options to serve the local subnet. A common setup for 
DNS service for an IPv4 subnet and IPv6 localhost is below. You can change the IPv4 subnet to 
match the subnet that you use, and add your IPv6 subnet if you have one. 

742 

# unbound.conf for a local subnet. 

743 

server: 

744 

interface: 0.0.0.0 

745 

interface : : : 0 


1.Source: unbound-1.5.9.tar.gz; SHA1 checksum: 4882c52aac0ab- 

cd72a86ac5d06e9cd39576620ce; SHA256 checksum: 

01328cfac99ab5b8c47115151896a244979e442e284eb962c0ea84b7782b6990; PGP signature: 
unbound-1.5.9.tar.gz.asc; License: BSD; Doc: man-page. 
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746 access-control: 192.168.0.0/16 allow 

747 access-control: ::1 allow 

748 verbosity: 1 

749 By default the software comes with chroot enabled. This provides an extra layer of defense 

750 against remote exploits. Enter file paths as full pathnames starting at the root of the filesystem 

751 ('/'). If chroot gives you trouble, you can disable it with chroot: "" in the config. Also the 

752 server assumes the username unbound to drop privileges. You can add this user with your 

753 favorite account management tool (useradd( 8 )), or disable the feature 1 with username: " " in 

754 the config. 

755 Start the server using the script (if you or the package manager installed one) as 

756 /etc/rc.d/init.d/unbound start, or unbound -c <config> as root. 

757 It is possible to setup remote control using unbound-control. First run 

758 unbound-control-setup to generate the necessary TLS key files (they are put in the default 

759 install directory). If you use a username of unbound to run the daemon from use sudo -u 

760 unbound unbound-control-setup to generate the keys, so that the server is allowed to read 

761 the keys. Then add the following at the end of the config file: 

762 # enable remote-control 

763 remote-control: 

764 control-enable: yes 

765 You can now use unbound-control to send commands to the daemon. It needs to read the key 

766 files, so you may need to sudo unbound-control. Only connections from localhost are allowed 

767 by default 


7682.6.3 Unbound Configuration for DNSSEC 

769 DNSSEC is a mechanism to protect DNS data. It uses digital signatures. To use DNSSEC with 

770 Unbound, the public keys for digital signature must be configured. Note that specific 

771 distributions, operating systems, or device vendors may have already provided the anchor, 

772 securing it with its own vendor-specific update mechanism. In that case, the mechanisms 

773 provided from those sources should be used. 


7742.6.3.1 Trust Anchor 


775 The first step in configuring Unbound for DNSSEC is to obtain an initial trust anchor . 2 The 

776 unbound-anchor tool provides an initial anchor from built-in values, but for real trust this 

777 should be checked thoroughly. The root key is stored in a file, 

778 /usr/local/etc/unbound/root. key. Unbound must be able to read and write it, to keep 

779 it up to date with the latest key(s). It must therefore reside within the chroot of Unbound (if 

780 that is used). Access rights are world-readable, user Unbound write only. Use sudo -u unbound 

781 to start unbound-anchor so that the file owner is set to the unbound user (same username as 

782 daemon uses). It can optionally be put somewhere else, accessible to the unbound daemon, 

783 such as /var/unbound or /etc. You need to pass this value to unbound-anchor (option -a 


1. Do not run as root. 

2. Unbound: How to enable DNSSEC, W.C.A. Wijngaards, NLnet Labs, April 2011. 
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816 

8172.6.3.3 

818 

819 

820 
821 
822 


file) and to unbound (auto-trust-anchor-file: "file" in unbound.conf). The unbound-anchor 

tool creates this file for the administrator if it does not exist. But the administrator must check 
this file so that it can be trusted. The unbound-anchor tool also has a built-in certificate (from 
the ICANN Certificate Authority) that it will use to update the root key if it becomes out of date, 
this should be checked too (-1 option to show it), or provide some other certificate that 

unbound-anchor is to use. 

There are trusted community representatives that have sworn and signed attestations, and 
there may be publications (i.e. in printed form). Please notice that NLnet Labs' unbound-anchor 
tool provides an initial value for convenience, systems administrators must perform the 
specified checks to obtain trust. The trust anchor can be downloaded via https from IANA: 
root-anchors.xml (click link and then check the lock icon and the urlbar and the hash displayed 
against the hash you can put as initial value into the root.key file, see below for an example of 
the syntax of how to input the initial value). 

Here is the 2010-2011 trust anchor for the root zone. This is the syntax that you can use to 
provide an initial value for the root.key file: 

. IN DS 19036 8 2 

49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 

Update Mechanism Setup 

Set the unbound-anchor tool to run at system startup, it is part of the Unbound package. A 
good way is to run it from the init scripts, with sudo -u unbound so that the file permissions 
work out. 

Before unbound-anchor is run inside the init scripts, you must run NTP (in secure mode), so 
that the time and date have been set properly. Unbound uses RFC 5011 updates to keep the 
anchor updated if it is changed while the computer is in operation, but the unbound-anchor 
tool is used if it is changed while the computer is not in operation. 

In the unbound.conf configfile, include the root anchor file with the automatic updated anchor 
statement, like this: 

server: 

# ... other stuff 

# root key file, automatically updated 

auto-trust-anchor-file: "/usr/local/etc/unbound/root.key" 

After you change the config, restart unbound. Unbound will then overwrite the key file with 
status information (such as the last time the key was seen). 

Testing Unbound Configurations for DNSSEC 

Entering dig com. soa tdnssec should result in display of the AD flag there. If this is 
unsuccessful, the Unbound option vai-iog-ievei : 2 should log explanations regarding why 
the DNSSEC validation fails (one line per failed query). Also, http://test.dnssec-or-not.org/ (fun 
test) or https://internet.nl/ (sober test) and http://www.kaminskybug.se/ (look for a happy bug 
icon) are useful test tools. 
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823 2.6.4 

Unbound Support 

824 

825 

Although it is open source software, support for Unbound is available from a number of 
sources, including NLnet Labs. 

8262. 7 

How to Install and Configure a DNS Signer Platform 

827 

828 

DNS Signer is a commercial product, the installation and configuration instructions can be 
obtained from the company website, http://www.secure64.com/. 

8292.7.1 

DNS Signer Installation Basics and System Requirements 

830 

Secure64 DNS Signer runs on HP Integrity servers with the following minimum configuration: 

831 

■ 1 dual core Itanium microprocessor 

832 

■ 4 GB RAM 

833 

■ 36 GB disk drive 

834 

■ DVD ROM drive 

835 

836 

DNS Signer is a commercial product. Information regarding obtaining the product can be found 

at http://www.secure64.com/contact. 

8372.7.2 

DNS Signer Installation and Configuration 

838 

839 

840 

DNS Signer can be configured to work with an authoritative DNS resolver, (e.g., DNS Authority) 
or a caching/recursive resolver (e.g., DNS Cache). The process followed for installation of DNS 
Signer at the NCCoE is included in Appendix H. 

841 2.8 

How to Install and Configure a DNS Authority 

842 

Platform 

843 

844 

845 

846 

847 

DNS Authority is a commercial product, the installation and configuration instructions can be 
obtained from the company website, http://www.secure64.com/. Information regarding 
obtaining the product can be found at http://www.secure64.com/contact. DNS Authority can 
be configured to work with a caching/recursive resolver (e.g., DNS Cache) and a DNS Signer. The 
process followed for installation of DNS Authority at the NCCoE is included in Appendix H. 

848 2.9 

How to Install and Configure DNS Cache 

849 

850 

851 

DNS Cache is a commercial product, installation and configuration instructions can be obtained 
from the company website, http://www.secure64.com/. Information regarding obtaining the 
product can be found at http://www.secure64.com/contact. 
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852 2.10 How to Install and Configure a Dovecot/Postfix Mail 
853 Transfer Agent 


854 2.10.1 Dovecot Installation Basics and System Requirements 

855 Dovecot can be downloaded from sources identified at the Dovecot Secure IMAP Server site 

856 (http://www.dovecot.org/download.html). 

857 2.10.1.1 Compiling Dovecot from Source Code 

858 To compile Dovecot from source code provide the following commands: 

859 ./configure 

860 make 

861 sudo make install 

862 That installs Dovecot under the /usr/local directory. The configuration file is in 

863 /usr/local/etc/dovecot. conf. Logging goes to syslog's mail facility by default, which 

864 typically goes to /var/log/mail.log or something similar. If you are in a hurry, you can then jump 

865 to QuickConfiguration. If you have installed some libraries into locations which require special 

866 include or library paths, you can pass them in the CPPFLAGS and LDFLAGS environment 

867 variables. For example: 

868 CPPFLAGS="-I/opt/openssl/include" LDFLAGS="-L/opt/openssl/lib" 

869 ./configure 

870 It is necessary to create two users for Dovecot's internal use: 

871 ■ dovenull: Used by untrusted imap-login and pop 3 -login processes (default_login_user 

872 setting). 

873 ■ dovecot: Used by slightly more trusted Dovecot processes (default_internal_user setting). 

874 Each of them should also have its own dovenull and dovecot groups. See 

875 http://wiki 2 .dovecot.org/Userlds for more information. 

8762.10.1.2 Compiling Dovecot from Git 

877 Dovecot is available from Git, for example with: 

878 git clone https://github.com/dovecot/core.git dovecot 

879 To compile Dovecot from Git, it is first necessary to run ./autogen. sh to generate the 

880 configure script and some other files. This requires that the following software/packages be 

881 installed: 

882 ■ autoconf 

883 ■ automake 

884 ■ libtool 

885 ■ pkg-config 

886 ■ gettext 
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887 ■ GNU make 

888 It is advisable to add --enable-maintainer-mode to the configure script: 

889 ./autogen. sh 

890 ./configure --enable-maintainer-mode 

891 make 

892 sudo make install 

893 For later updates, the commands are: 

894 git pull 

895 make 

896 sudo make install 


8972.10.1.3 Compiling Dovecot with rpmbuild (Mandriva, RedHat, etc.) 

898 Fetch the source rpm from ftp://ftp.surfnet.nl/ or any other mirror. Currently, 

899 dovecot-10.rc26.src.rpm can be found in the cooker subtree. If the current release is newer, 
unpack the source rpm with rpm -ivh dovecot-10. rc26. src. rpm to a build environment 

901 (/usr/src/rpm. . .) Copy the newer tarball from the dovecot site to the SOURCES directory 

902 of the build environment. Change the dovecot.spec file in the SPECS directory to reflect the 

903 new release and the new name of the tarball. The maintainer works with a bz2 tarball; a tar.gz 

904 tarball makes no difference. Issue a rpmbuild -ba dovecot.spec. The resulting rpm will be 

905 placed in RPMS/i586 . Install with rpm or urpmi: 

906 rpm -ivh dovecot-1.0 . rc2 6 . src . rpm 

907 cd /usr/src/rpm 

908 mv ~/downloads/dovecot-l.0.rc28.tar.gz ./SOURCES 

909 cd SPECS 

910 vi dovecot.spec 

911 ...edit release and tarball name. Change default options if needed... 

912 rpmbuild -ba dovecot.spec 

913 cd ../RPMS/i586 

914 urpmi ./dovecot-1.0 . rc28-lmdv2007.0.1586 . rpm 

915 During this process missing prerequisites may be detected. Install them and rerun the build 

916 process. The spec file also need updating for the new add-ons (idxview and logview). 

9172.10.1.4 SSL/TLS Support 

918 Dovecot was initially built to support both OpenSSL and GNUTLS, but OpenSSL is currently used 

919 by default, and it should be automatically detected. If it is not, some header files or libraries are 

920 missing, or they are in a non-standard path. The openssl-dev or a similar package needs to be 

921 installed, and if it is not in the standard location, set CPPFLAGS and LDFLAGS as shown above. 

922 By default the SSL certificate is read from /etc/ssl/certs/dovecot .pem, and the private 

923 key from /etc/ssl/private/dovecot .pem. The /etc/ssl directory can be changed using 

924 the —with-ssldir=DiR configure option. Both can of course be overridden from the 

925 configuration file. 
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926 

927 

928 

929 

930 

931 

932 

933 

934 

935 

936 

937 

938 

939 

940 2.10.1. 

941 

942 

943 

944 

945 

946 

947 

948 

949 

950 

951 

952 

953 

954 

955 

956 

957 

958 

959 

960 

961 

962 

963 

964 

965 


For Linux installations, note that current inotify is in the Linux kernel since version 2 . 6.13 and it 
is preferred over dnotify. If your distribution does not have the required inotify header file, it 
can be obtained from the inotify maintainer (the following example requires cURL): 

mkdir -p /usr/local/include/sys 
cd /usr/local/include/sys 
curl 

ftp://ftp.kernel.org/pub/linux/kernel/people/rml/inotify/headers/inoti 

fy.h -0 

curl 

ftp://ftp.kernel.org/pub/linux/kernel/people/rml/inotify/headers/inoti 
fy-syscalls.h >> inotify.h 

/usr/local/include isn't in standard include lookup path, so that needs to be specified to 
configure: 

CPPFLAGS=-I/usr/local/include ./configure --with-notify=inotify 


5 Dovecot Configuration Options 

■ --help 

gives a full list of available options 

■ --help=short 

just lists the options added by the particular package (= Dovecot) 

Options are usually listed as — with-something or — enable-something. If you want to disable 
them, do it as — without-something or — disable-something. There are many default 
options that come from autoconf, automake or libtool. The list of options that Dovecot adds 
follows: 

■ --enable-devel-checks 

Enables some extra sanity checks. This is mainly useful for developers. It does quite a lot of 
unnecessary work but should catch some programming mistakes more quickly. 

■ —enable-asserts 

Enable assertion checks, enabled by default. Disabling them may slightly save some CPU, 
but if there are bugs they can cause more problems since they are not detected as early. 

■ --without-shared-libs 

Link Dovecot binaries with static libraries instead of dynamic libraries. 

■ —disable-largefile 

Specifies if we use 32 bit or 64 bit file offsets in 32 bit CPUs. 64 bit is the default if the system 
supports it (Linux and Solaris do). Dropping this to 32 bit may save some memory, but it 
prevents accessing any file larger than 2 GB. 

■ --with-mem-align=BYTES 

Specifies memory alignment used for memory allocations. It is needed with many non-x86 
systems and it should speed up x86 systems too. Default is 8, to make sure 64 bit memory 
accessing works. 

■ --with-ioloop=IOLOOP 
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966 

967 


969 

970 

971 


Specifies what I/O loop method to use. Possibilities are select, poll, epoll and kqueue. The 
default is to use the best method available on your system. 

—with-notify=NOTIFY 

Specifies what file system notification method to use. Possibilities are dnotify, inotify (both 
on Linux), kqueue (FreeBSD) and none. The default is to use the best method available on 
your system. See Notify method above for more information. 


972 

973 

974 


--with-storages=FORMATS 

Specifies what mailbox formats to support. Note: Independent of this option, the formats 
raw and shared will be always built. 


975 ■ —with-solr 

976 Build with Solr full text search support 


977 ■ --with-zlib 

978 Build with zlib compression support (default if detected) 


979 ■ --with-bzlib 

980 Build with bzip 2 compression support (default if detected) 


98i SQL Driver Options 


982 

983 

984 

985 

986 

987 


SQL drivers are typically used only for authentication, but they may be used as a lib-dict 
backend too, which can be used by plugins for different purposes. 

■ --with-sql-drivers 

Build with specified SQL drivers. Defaults to all that were found with autodetection. 

■ —with-pgsql 

Build with PostgreSQL support (requires pgsql-devel, libpq-dev or similar package) 

■ --with-mysql 


989 

990 

991 


Build with MySQL support (requires mysql-devel, Iibmysqlclientl 5 -dev or similar package) 

■ --with-sqlite 

Build with SQLite 3 driver support (requires sqlite-devel, IibsqIite 3 -dev or similar package) 


992 Authentication Backend Options 


993 

The basic backends are built if the system is detected to support the 

994 

■ 

--with-shadow 

995 


Build with shadow password support 

996 

■ 

--with-pam 

997 


Build with PAM support 

998 

■ 

--with-nss 

999 


Build with NSS support 

1000 

■ 

--with-sia 

1001 


Build with Tru 64 SIA support 

1002 

■ 

--with-bsdauth 

1003 


Build with BSD authentication support (if supported by your OS) 
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1004 

1005 

1006 

1007 

1008 

1009 

1010 

1011 

1012 

1013 

1014 

1015 


Some backends require extra libraries and are not necessarily wanted, so they are built only if 
specifically enabled: 

■ --with-sql 

Build with generic SQL support (drivers are enabled separately) 

■ --with-ldap 

Build with LDAP support (requires openldap-devel, Iibldap2-dev or similar package) 

■ --with-gssapi 

Build with GSSAPI authentication support (requires krb5-devel, Iibkrb5-dev or similar 
package) 

■ --with-vpopmail 

Build with vpopmail support (requires vpopmail sources or a development package) 

It's also possible to build these as plugins by giving e.g. — with-sqi=piugin. 


10162.10.1.6 Dovecot Support 

ion Although Dovecot is open source software, support is available from dovecot.org and 

ioi8 commercial sources. See http://www.dovecot.org/support.html. 


ioi 92.10.2 Postfix Installation and Configuration 


1020 

1021 

1022 

1023 

1024 


Postfix was released under the IBM Public License, and source code can be downloaded from 

http://cdn.postfix.johnriley.me/mirrors/postfix-release/index.html. All Postfix source code is 
signed with Wietse's PGP key. 1 Instructions for installing Postfix from source code can be found 

at http://www.postfix.org/INSTALL.html. Postfix manual pages can be found at 
http://www.postfix.org/postfix-manuals.html. 


1025 2.10.2.1 Installation and System Requirements 


1026 

1027 

1028 

1029 

1030 

1031 


If you are using a pre-compiled version of Postfix, you should start with 
BASIC_CONFIGURATION_README and the general documentation referenced by it. INSTALL is 
only a bootstrap document to get Postfix up and running from scratch with the minimal number 
of steps; it is not considered part of the general documentation. The INSTALL document 
describes how to build, install and configure a Postfix system so that it can do one of the 
following: 


1032 


Send mail only, without changing an existing Sendmail installation. 


1033 

1034 


Send and receive mail via a virtual host interface, still without any change to an existing 
Sendmail installation. 


1035 


Run Postfix instead of Sendmail. 


1 . See ftp://ftp.porcupine.org/mirrors/project-history/postfix/for a more extensive archive of 
tarballs. 
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1036 

1037 

1038 

1039 

1040 

1041 

10422.10.2.2 

1043 

1044 

1045 

1046 

1047 

1048 

1049 

1050 

1051 

1052 

1053 

1054 

1055 

1056 

1057 

1058 

1059 

1060 
1061 
1062 

1063 

1064 2.10.2.3 

1065 

1066 

1067 

1068 

1069 

1070 

1071 

1072 


According to INSTALL, Postfix development is conducted on FreeBSD and MacOS X, with regular 
tests on Linux (Fedora, Ubuntu) and Solaris. Support for other systems relies on feedback from 
their users, and may not always be up-to-date. OpenBSD is partially supported. The libc resolver 
does not implement the documented "internal resolver options which are [...] set by changing 
fields in the _res structure" (documented in the OpenBSD 5.6 resolver( 3 ) manpage). This results 
in too many DNS queries, and false positives for queries that should fail. 

Compiler Specifics 

If you need to build Postfix for multiple architectures from a single source-code tree, use the 
lndir command to build a shadow tree with symbolic links to the source files. If at any time in 
the build process you get messages like: make: don't know how to ... you should be 
able to recover by running the following command from the Postfix top-level directory: 

$ make -f Makefile.init makefiles 

If you copied the Postfix source code after building it on another machine, it is a good idea to cd 
into the top-level directory and first do this: 

$ make tidy 

This will get rid of any system dependencies left over from compiling the software elsewhere. 

To build with GCC, or with the native compiler if people told me that is better for your system, 
just cd into the top-level Postfix directory of the source tree and type: 

$ make 

To build with a non-default compiler, you need to specify the name of the compiler, for 
example: 

$ make makefiles CC=/opt/SUNWspro/bin/cc (Solaris) 

$ make 

$ make makefiles CC="/opt/ansic/bin/cc -Ae (HP-UX) 

$ make 

$ make makefiles CC="purify cc" 

$ make 

In some cases, optimization will be turned off automatically. 

Building with Position-Independent Executables 

On some systems Postfix can be built with Position-Independent Executables. PIE is used by the 
ASLR exploit mitigation technique (ASLR = Address-Space Layout Randomization). 

$ make makefiles pie=yes ...other arguments... 

(Specify make makefiles pie=no to explicitly disable Postfix position-independent executable 
support). Postfix PIE support appears to work on Fedora Core 20 , Ubuntu 14 . 04 , FreeBSD 9 and 
10 , and NetBSD 6 (all with the default system compilers). Whether the pie=yes above has any 
effect depends on the compiler. Some compilers always produce PIE executables, and some 
may even complain that the Postfix build option is redundant. 
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1073 2.10.2.4 Dynamically Linked Libraries 

1074 Postfix dynamically-linked library and database plugin support exists for recent versions of 

1075 Linux, FreeBSD and MacOS X. Note that dynamically-linked library builds may become the 

1076 default at some point in the future. 

10772.10.2.5 Default Settings and Optional Features 

1078 By default, Postfix builds as a mail system with relatively few bells and whistles. Support for 

1079 third-party databases etc. must be configured when Postfix is compiled. The following 

1080 documents describe how to build Postfix with support for optional features: 


Table 2.5 Postfix Default Settings and Optional Features 


Optional Feature 

Document 

Availability 

Berkeley DB database 

DB_README 

Postfix 1.0 

LMDB database 

LMDB_README 

Postfix 2.11 

LDAP database 

LDAP_README 

Postfix 1.0 

MySQL database 

MYSQL_README 

Postfix 1.0 

Perl compatible regular expression 

PCRE_README 

Postfix 1.0 

PostgreSQL database 

PGSQL_README 

Postfix 2.0 

SASL authentication 

SASL_README 

Postfix 1.0 

SQLite database 

SQLITE_README 

Postfix 2.8 

STARTTLS session encryption 

TLS_README 

Postfix 2.2 


1082 Note: IP version 6 support is compiled into Postfix on operating systems that have IPv6 support. 

1083 See the IPV6 README file for details. 


10842.10.2.6 Installing After Compiling 


1085 1 . Save existing Sendmail binaries 


1086 

1087 

1088 

1089 

1090 

1091 


Some systems implement a mail switch mechanism where different MTAs (Postfix, 
Sendmail, etc.) can be installed at the same time, while only one of them is actually being 
used. Examples of such switching mechanisms are the FreeBSD mailwrapper( 8 ) or the Linux 
mail switch. In this case you should try to "flip" the switch to "Postfix" before installing 
Postfix. If your system has no mail switch mechanism, execute the following commands 
(your sendmail, newaliases and mailq programs may be in a different place): 


1092 

1093 

1094 

1095 

1096 

1097 


?# mv /usr/sbin/sendmail /usr/sbin/sendmail.OFF 

# mv /usr/bin/newaliases /usr/bin/newaliases.OFF 

# mv /usr/bin/mailq /usr/bin/mailq.OFF 

# chmod 755 /usr/sbin/sendmail.OFF/usr/bin/newaliases.OFF\ 
/usr/bin/mailq.OFF 

2 . Create account and groups 
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1128 
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1131 

11322.10.2.7 

1133 

1134 

1135 

1136 


Before you install Postfix for the first time you need to create an account and a group: 

a. Create a user account postfix with a user id and group id that are not used by any other 
user account. Preferably, this is an account that no-one can log into. The account does 
not need an executable login shell, and needs no existing home directory. Sample 
password and group file entries follow: 

/etc/passwd: 

postfix:*:12345:12345:postfix:/no/where:/no/she11 
/etc/group: 
postfix:*:12345: 

Note: there should be no whitespace before postfix:. 

b. Create a group postdrop with a group id that is not used by any other user account. Not 
even by the postfix user account. An example of a group file entry follows: 

/etc/group: 
postdrop:*:54321: 

Note: there should be no whitespace before postdrop:. 

3 . Install Postfix 

To install or upgrade Postfix from compiled source code, run one of the following 
commands as the super-user: 

# make install (interactive version, first time install) 

# make upgrade (non-interactive version, for upgrades) 

a. The interactive version (make install) asks for pathnames for Postfix data and 
program files, and stores your preferences in the main.cf file. If you don't want Postfix 
to overwrite non-Postfix sendmail, mailq and newaliases files, specify pathnames that 
end in .postfix. 

b. The non-interactive version (make upgrade) needs the /etc/postfix/main. cf file 
from a previous installation. If the file does not exist, use interactive installation (make 
install) instead. 

If you specify name=value arguments on the make install or make upgrade command 
line, then these will take precedence over compiled-in default settings or main.cf 
settings. The command make install/upgrade name=vaiue . .. will replace the 
string maiinversion at the end of a configuration parameter value with the Postfix 
release version. Do not try to specify something like $mail_version on this command 
line. This produces inconsistent results with different versions of the make(l) 
command. 

Configure Postfix 

See http://www.postfix.Org/postconf. 5 .html for Postfix configuration parameters. 

Note: The material covered in this section from INSTALL Section 10 is covered in more detail in 
the BASIC_CONFIGURATION_README document. The information presented below is 
targeted at experienced system administrators. 
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1 . Postfix configuration files 

By default, Postfix configuration files are in /etc/postfix. The two most important files 
are main.cf and master.cf; these files must be owned by root. Giving someone else write 
permission to main.cf or master.cf (or to their parent directories) means giving root 
privileges to that person. In /etc/postf ix/main. cf, you will have to set up a minimal 
number of configuration parameters. Postfix configuration parameters resemble shell 
variables, with two important differences: the first one is that Postfix does not know about 
quotes like the UNIX shell does. You specify a configuration parameter as: 

/etc/postfix/main.cf: 
parameter = value 

and you use it by putting a "$" character in front of its name: 

/etc/postfix/main.cf: 

other_parameter = $parameter 

You can use $parameter before it is given a value (that is the second main difference with 
UNIX shell variables). The Postfix configuration language uses lazy evaluation, and does not 
look at a parameter value until it is needed at runtime. Whenever you make a change to the 
main.cf or master.cf file, execute the following command in order to refresh a running mail 
system: 

# postfix reload 

2 . Default domain for unqualified addresses 

First of all, you must specify what domain will be appended to an unqualified address (i.e. 
an address without @domain.tld). The myorigin parameter defaults to the local hostname, 
but that is intended only for very small sites. 

Some examples (use only one): 

/etc/postfix/main.cf: 

myorigin = $myhostname (send mail as "user@$myhostname") 
myorigin = $mydomain (send mail as "user@$mydomain") 

3 . Specification of what domains to receive locally 

Next you need to specify what mail addresses Postfix should deliver locally. 

Some examples (use only one): 

/etc/postfix/main.cf: 

mydestination = $myhostname, localhost.$mydomain, localhost 

mydestination = $myhostname, localhost.$mydomain, 
localhost,$mydomain 

mydestination = $myhostname 

The first example is appropriate for a workstation, the second is appropriate for the mail 
server for an entire domain. The third example should be used when running on a virtual 
host interface. 

4 . Proxy/NAT interface addresses 
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The proxy_interfaces parameter specifies all network addresses that Postfix receives mail 
on by way of a proxy or network address translation unit. You may specify symbolic 
hostnames instead of network addresses. 

IMPORTANT: You must specify your proxy/NAT external addresses when your system is a 
backup MX host for other domains, otherwise mail delivery loops will happen when the 
primary MX host is down. 

Example: host behind NAT box running a backup MX host. 

/etc/postfix/main.cf: 

proxy interfaces = 1.2.3.4 (the proxy/NAT external network address) 

5 . Specification of What local clients to relay mail from 

If your machine is on an open network then you must specify what client IP addresses are 
authorized to relay their mail through your machine into the Internet. The default setting 
includes all subnetworks that the machine is attached to. This may give relay permission to 
too many clients. For example: 

/etc/postfix/main.cf: 

mynetworks = 168.100.189.0/28, 127.0.0.0/8 

6. Specification of what relay destinations to accept from strangers 

If your machine is on an open network then you must also specify whether Postfix will 
forward mail from strangers. The default setting will forward mail to all domains (and 
subdomains of) what is listed in $mydestination. This may give relay permission for too 
many destinations. Recommended settings (use only one): 

/etc/postfix/main.cf: 

relay domains = (do not forward mail from strangers) 
relay_domains = $mydomain (my domain and subdomains) 
relay_domains = $mydomain, other.domain.tld, ... 

7 . Optional: configure a smart host for remote delivery 

If you're behind a firewall, you should set up a relayhost. If you can, specify the 
organizational domain name so that Postfix can use DNS lookups, and so that it can fall back 
to a secondary MX host when the primary MX host is down. Otherwise just specify a 
hard-coded hostname. Some examples follow (use only one): 

/etc/postfix/main.cf: 
relayhost = $mydomain 
relayhost = [mail.$mydomain] 

The form enclosed with [] eliminates DNS MX lookups. By default, the SMTP client will do 
DNS lookups even when you specify a relay host. If your machine has no access to a DNS 
server, turn off SMTP client DNS lookups like this: 

/etc/postfix/main.cf: 
disable_dns_lookups = yes 

The STANDARD_CONFIGURATION_README file has more hints and tips for firewalled 
and/or dial-up networks. 
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8. Create the aliases database 
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Postfix uses a Sendmail-compatible aliases( 5 ) table to redirect mail for local(8) recipients. 
Typically, this information is kept in two files: in a text file /etc/aliases and in an indexed file 
/etc/aliases . db. The command postconf alias_maps will tell you the exact location 
of the text file. First, be sure to update the text file with aliases for root, postmaster and 
postfix that forward mail to a real person. Postfix has a sample aliases file 
/etc/postfix/aliases that you can adapt to local conditions. 

/etc/aliases: 
root: you 
postmaster: root 
postfix: root 
bin: root 
etcetera... 

Note: there should be no whitespace before the Finally, build the indexed aliases file 
with one of the following commands: 

# newaliases 

# sendmail -bi 

9 . Setting up chroot 

Postfix daemon processes can be configured (via master.cf) to run in a chroot jail. The 
processes run at a fixed low privilege and with access only to the Postfix queue directories 
(/var/spool/postfix). This provides a significant barrier against intrusion. Note that 
this barrier is not impenetrable, but every little bit helps. With the exception of Postfix 
daemons that deliver mail locally and/or that execute non-Postfix commands, every Postfix 
daemon can run chrooted. 

Sites with high security requirements should consider to chroot all daemons that talk to the 
network: the smtp(8) and smtpd(8) processes, and perhaps also the lmtp(8) client. The 
default /etc/postfix/master. cf file specifies that no Postfix daemon runs chrooted. In 
order to enable chroot operation, edit the file /etc/postfix/master. cf . Instructions 
are in the file. 

Note also that a chrooted daemon resolves all filenames relative to the Postfix queue 
directory (/var/spool/postfix). For successful use of a chroot jail, most UNIX systems 
require you to bring in some files or device nodes. The examples/chroot-setup directory in 
the source code distribution has a collection of scripts that help you set up Postfix chroot 
environments on different operating systems. 

Additionally, you need to configure syslogd so that it listens on a socket inside the Postfix 
queue directory. Examples for specific systems: 

FreeBSD: 

# mkdir -p /var/spool/postfix/var/run 

# syslogd -1 /var/spool/postfix/var/run/log 

Linux, OpenBSD: 
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1256 # mkdir -p /var/spool/postfix/dev 

1257 # syslogd -a /var/spool/postfix/dev/log 


1258 2.10.3 Postfix Installation and Configuration for use with Dovecot 


1259 

1260 
1261 
1262 


The following elements are necessary for setting up Postfix for Dovecot 1 : 

■ Adomainsuchasmydomain.com 

■ A hostname for your mail server such as mail.mydomain.com 

■ An SSL certificate that is valid for mail.mydomain.com 


1263 2.10.3.1 Setting up SSL Certificate 


1264 

1265 

1266 

1267 

1268 
1269 


For SSL, you need a certificate and a private key saved in a location such as 

/etc/ssl/certs/mailcert.pem and the key is saved (e.g., in 

/etc/ssl/private/mail. key). Make sure the key is only readable by the root user. How to 
set up SSL certificates for your website and e-mail depends on your website structure and the 
CA you use (self-signed, organizational (sub)-ca, or commercial ca for example). Creating a 
self-signed test certificate is as easy as executing 


1270 sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout 

1271 /etc/ssl/private/mail. key -out /etc/ssl/certs/mailcert.pem 2 


1272 and leaving the default values in by just hitting enter on all questions asked. 


1273 Most CAs will require you to submit a certificate signing request. (CSR) You can generate one 

1274 like this: 


1275 sudo openssl req -nodes -days 365 -newkey rsa:2048 -keyout 

1276 /etc/ssl/private/mail. key -out mailcert.csr 


1277 Fill in the information queried properly, like in this transcript: (Check with the CA you intend to 

1278 use on what information needs to be in the CSR) 


1279 

1280 
1281 
1282 


Specific instructions for acquisition of certificates from CAs can be obtained from the CA. An 
example is provided at: 

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-server-wi 

th-dovecot. 


1283 2.10.3.2 Setting up DNS 

1284 You still have to set up the DNS with an a record that points to your mail server IP and an MX 

1285 record that points to the mail servers hostname. Instructions for the standard configuration for 

1286 Postfix can be found at http://www.postfix.org/STANDARD_CONFIGURATION_README.html. 


1. See How To Set Up a Postfix E-Mail Server with Dovecot, DigitalOcean, November 14, 2013. 

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-e-mail-serv- 

er-with-dovecot 

2. Don't use this certificate in your system. 
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1287 2.11 How to Install and Configure a Thunderbird Mail 

1288 Client 

1289 The starting point for installing Thunderbird can be found at 

1290 https://support.mozilla.org/en-US/kb/installing-thunderbird, and the initial step is to click on 

the icon designating the operating system on which Thunderbird is being installed (Windows, 

1292 Mac, or Linux). 


12932.1 1.1 Thunderbird Installation Basics and System Requirements 


System requirements for installing Thunderbird 45.2.0 on Windows, Mac, and Linux operating 

1295 systems can be found at 

1296 https://www.mozilla.Org/en-US/thunderbird/45.2.0/system-requirements/. 


12972.1 1.2 Thunderbird Installation and Configuration on Windows 


1298 

1299 

1300 

1301 

1302 

1303 

1304 


Instructions for installing Thunderbird in Windows environments can be found at 
https://support.mozilla.org/en-US/kb/installing-thunderbird-windows. Selecting Download 
will download Thunderbird on the disk image Thunderbird 45.2.0.dmg. After starting the 
process by clicking Run, the Mozilla Thunderbird Setup Wizard will be started. Closing all other 
applications before starting Setup will make it possible to update relevant system files without 
having to reboot the computer. After installation, double-clicking on the Thunderbird icon runs 
the program. 


1305 2.1 1.3 Thunderbird Installation and Configuration on Linux 


1306 

1307 

1308 

1309 

1310 


Instructions for installing Thunderbird on Linux can be found at 

https://support.mozilla.org/en-US/kb/installing-thunderbird-linux. To install Thunderbird using 
the package manager, it is necessary to refer to the documentation of the Linux distribution 
you're using. Complete instructions for installing Thunderbird outside of package management 
may be available at a distribution support website (e.g., Installing Thunderbird on Ubuntu). 


mi 2.11.4 Thunderbird Installation and Configuration on Mac 


1312 

1313 

1314 

1315 

1316 

1317 

1318 

1319 

1320 

1321 

1322 

1323 


Instructions for installing Thunderbird on Mac machines can be found at 
https://support.mozilla.org/en-US/kb/installing-thunderbird-on-mac. The Thunderbird 
download page automatically detects the platform and language on the computer accessing it. 
To download Thunderbird in a language other than the one suggested, click on Other Systems 
& Languages for the list of available editions. Click on the OS X installation of your choice to 
continue. Once the download is completed, the disk image may open by itself and mount a new 
volume which contains the Thunderbird application. If you do not see the new volume, 
double-click the Thunderbird dmg icon to open it. A Finder window appears, containing the 
Thunderbird application. Drag the Thunderbird icon to the Applications folder. At this point you 
can eject the disk image by selecting it in a Finder window and pressing the command+E keys 
or by using the Finder's File menu, and selecting Eject. Open the Applications folder and 
double-click on the Thunderbird icon to start it. You may get a security warning that 
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1324 Thunderbird has been downloaded from the Internet. Because you downloaded Thunderbird 

1325 from the official site, you can click Open to continue. The first time you start Thunderbird you 

1326 will be alerted that it is not your default email application. (The default email application is the 

1327 program that opens, for example, when you click a link on a web page to an email address.) If 

1328 you want Thunderbird to be the default email application, click Yes to set it as your default 

1329 mailer. If not (for example if you are just trying out Thunderbird) click No. 


1330 2.11.5 Thunderbird Configuration for use with Microsoft Exchange 


1331 Thunderbird can be used to access Microsoft Exchange servers that support IMAP or POP3. The 

1332 normal way to use Thunderbird with a Microsoft Exchange Server requires the system 

1333 administrator to enable the POP/IMAP/SMTP mail servers that are bundled with that server. 

1334 Otherwise, since Exchange uses a proprietary MAPI protocol, accessing Exchange from 

1335 Thunderbird can require a plugin or gateway 1 that provides standard, compliant protocols in 

1336 front of proprietary Exchange (e.g., DavMail, ExQuilla). 

1337 In setting up Thunderbird: 


1338 1. Open Thunderbird and click the Tools menu option. Click Account Settings. Click Account 

1339 Settings again to start the process for the Exchange connection. 


1340 2. Enter the full name at the first window. This name is what email recipients see in their 

1341 inbox. In the following text box, enter your email address. Click the Next button. 


1342 

1343 

1344 


3. Select IMAP Mail Server from the drop-down window. Enter the Exchange server name in 
the IMAP Server Name text box. In the Outgoing Server text box, enter the Exchange server 
name again. Click the Next button. 


1345 

1346 

1347 

1348 


4. Check the box labeled Username and password. Enter your current username used to log 
into the machine. Remove the check mark in the box labeled Use secure connection. Click 
Finish. The Thunderbird application is ready to send and receive email from the Exchange 
server. 


13492.1 1.6 Thunderbird Configuration for use with Dovecot/Postfix 

1350 General step-by-step instructions for setting up Thunderbird can be found at 

1351 https://products.secureserver.net/email/email_thunderbird.htm (Setting Up Your POP or IMAP 

1352 Email Address with Mozilla Thunderbird). 

1353 Instructions for automatic account configuration can be found at 

1354 https://support.mozilla.org/en-US/kb/automatic-account-configuration. Manual account 

1355 configuration requires the following information: 

1356 ■ incoming mail server and port (for example, pop.example.com and port 110 or 

1357 imap.example.com and port 143) 

1358 ■ outgoing mail server and port (for example, smtp.example.com and port 25) 


1 . Several links to free and commercial gateway and add-on products can be found by using a 
search engine with the argument "how to configure Microsoft Exchange server in Thunderbird." 
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1359 ■ security setting for the connection with the server (for example, STARTTLS or SSL/TLS and 

1360 whether or not to use secure authentication) 

1361 Instructions can be found at 

1362 https://support.mozilla.org/en-US/kb/manual-account-configuration. 


1363 2.1 1.7 Thunderbird Support 

1364 Although it is open source software, Thunderbird support is available from Mozilla and other 

1365 sources. 
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8 

9 

10 

11 

12 

13 

14 

This section provides additional information regarding for installing, configuring and operating 
Email and DNS security applications. Section 3.1 provides specific recommendations regarding 
certificate generation. Section 3.2 describes cryptographic operation and management by users 
on Outlook and Thunderbird. Section 3.3 describes setting up Exchange and Postfix MTAs to 
provide server-to-server encryption of email. Section 3.4 provides links to some tools and 
utilities that are useful in installing, configuring, provisioning, and maintaining DNS-based email 
security software. 

15 

16 

17 

18 

19 

It is recommended that the installation, configuration, and operation of DNS servers be 
conducted in conformance to NIST SP 800 - 81 - 2 , the Secure Domain Name System (DNS) 
Deployment Guide. Appendix D provides a checklist for management of secure DNSs. 
Installation, configuration, and operation of email applications should follow the 
recommendations of SP 800 - 177 , Trustworthy Email. 

*3.1 

Using SSL for Cryptographic Certificate Generation 

21 

22 

23 

24 

25 

OpenSSL is a widely used open-source implementation of TLS/SSLand supporting cryptographic 
libraries for various version of Linux, but can also be used with Mac OS. OpenSSL also contains 
user utilities for generating cryptographic keys, certificate requests, and X .509 certificates. 
There is a FIPS -140 approved version of relevant OpenSSL cryptographic modules available for 
use by federal agencies. 

263.1.1 

OpenSSL Installation Basics and System Requirements 

27 

28 

29 

30 

31 

32 

33 

OpenSSL components and libraries are often standard components in base Linux installs, or can 
be installed using the built-in repository management system used with the version of Linux in 
use (e.g. apt-get, yum, rpm, etc.). Administrators may wish to install the developer repositories 
(*-devel or *-src) to make sure that all necessary header files are installed to support server 
implementations that rely on OpenSSL for cryptographic support. The latest version of 
OpenSSL, as well as FIPS approved versions may not be available in repositories and may need 
to be built from source from the OpensSSL project homepage 1 . 

34 

35 

36 

In addition to having a base supported operating system, OpenSSL requires Perl 5 and a C 
compiler and development environment (with tools like make) to be successfully compiled and 
installed. 

373.1.1.1 

OpenSSL FIPS Approved Installation 

38 

39 

40 

41 

42 

43 

Federal agencies or other organizations that are required to use FIPS -140 approved 
cryptographic modules can use OpenSSL FIPS approved version. These necessary modules are 
not always available via OS-specific repositories, but must be manually downloaded and 
compiled. The newly compiled libraries then replace any older, or pre-installed versions 2 . 
Server daemons (e.g. BIND named, postfix, etc.) that rely on OpenSSL for cryptographic support 
will then use the FIPS -140 approved version of the libraries. 


1. https://openssl.org/ 

2. https://wiki. 0 penssl. 0 rg/index.php/C 0 mpilati 0 n_and_lnstallati 0 n#FIPS_Capable_Library 
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44 


3.1.1.2 OpenSSL Installation on Mac OS 


45 

46 

47 

48 

49 


Normally, there is no need to install a separate set of cryptographic libraries for Mac OS. 
OpenSSL is installed in the standard Mac OS distribution provides the same functionality 
However, if there is a desire to upgrade the standard installation an alternative repository tool 
(e.g. homebrew 1 ) may be necessary or certain files need to be changed 2 in order to build 
OpenSSL on an Apple system. 


50 


3.1.2 OpenSSL Configuration 


51 3.1.2.1 Configuration of OpenSSL to act as a Local Certificate Authority (CA) 

52 OpenSSL can be used to generate certificates and act as a local enterprise Certificate Authority 

53 (CA). This is not always advisable as it is very bare-boned set of tools. Enterprises using OpenSSL 
as their CA must take great care to insure that the root certificate (i.e. the CA certificate that 

55 signs all the end-entity certificates) is adequately protected. Compromise of the root certificate 

56 private key would allow an attacker to generate arbitrary certificates for spoofed hosts and 

57 services. How this root certificate private key is protected is beyond the scope of this document 

58 but should include adequate physical, access, and logical controls. 

59 OpenSSL can be used via the openssl command line tool to generate key pairs, and certificates 

60 for those key pairs. This certificate generation can be done by adding the certificate data on the 

61 command line, or using a configuration file for (organizational) default values. For example, if 

62 the organizational policy is for all certificates to have a lifetime of one year (365 days), that 

63 value can be set in a configuration file and does not need to be set using command line options 

64 unless there is a need to override the default for a specially generated certificate. 

65 The general order in setting up OpenSSL to operate an enterprise local CA (or to generate 

66 self-signed certificates) is to: Generate and set up configuration files, generate the root 

67 certificate, and finally, generate and sign end entity certificates. 


68 3.1.2.2 The OpenSSL CA Configuration File 

69 Once OpenSSL is installed on the system, the CA admin needs to find and edit the opnessl.cnf 

70 configuration file. Where this file is located depends on how OpenSSL was installed on the 

71 system. Many repository installations will put the file at /etc/ssl/openssl. cnf but it may 

72 also be found at /usr/ssl or /usr/openssl or some other directory. 

73 The configuration file is broken down into blocks around openssl commands. Most of these 

74 blocks can be left in their default values unless there is a specific policy reason for changing 

75 them. The two blocks that enterprise CA admins will likely need to change is [ CA_default ] and 

76 [ req ] which contain the default values for cryptographic and hash algorithms, default sizes and 

77 lifetimes, and Distinguished Name (country, organizational name, Common Name, etc.) 

78 respectively. An example snippet of the configuration file openssl.cnf is given in figure 3.1 

79 below. 


1. http://brew.sh/ 

2. https://wiki.openssl.Org/index.php/Compilation_and_lnstallation#Mac 
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so The values in the [ CA_defaults ] block deal with the components of the CA itself: the 

81 directories used, the serial number file, etc. These are used to manage the CA itself, not directly 

82 involved with the cryptographic operation of generating key pairs and certificates. CA 

83 administrators can set these values to the appropriate directories for their enterprise CA. 

84 OpenSSL does not generate some of the necessary directories and files (such as serial, which 

85 keeps track of the serial numbers of issues certificates). These will need to be created by the 

86 admin using a text editor or standard Linux commands. 

87 The values in the [ req ] block deal with the identification data and characteristics of X.509 

88 certificates generated by the CA. These values will most likely need to be edited by enterprise 

89 CA administrators. If the enterprise certificate policy dictates that some values must be 

90 constant across the organization, it makes sense to make them the default values in the 

91 configuration file. For example, the enterprise always wants its HQ location used as the country, 

92 state, and locality in every certificate it generates. 
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93 Figure 3.1 Example OpenSSL Configuration File 


[ CA_default ] 


dir = /etc/pki/CA 

certs = $dir/certs 
crl_dir = $dir/crl 

database = $dir/index.txt 

#unique_subject = no 


new certs dir 


# Where everything is kept 

# Where the issued certs are kept 

# Where the issued crl are kept 

# database index file. 

# Set to 'no' to allow creation of 
# several ctificates with same subject. 

$dir/newcerts # default place for new certs. 


certificate = $dir/cacert.pem # The CA certificate 

serial = $dir/serial # The current serial number 

crlnumber = $dir/crlnumber # the current crl number 

# must be commented out to leave a VI CRL 
crl = $dir/crl.pem # The current CRL 

private_key = $dir/private/cakey.pem# The private key 
RANDFILE = $dir/private/.rand # private random number file 


x509 extensions 


= usr cert 


# The extentions to add to the cert 


I req ] 

default_bits 

default_md 

default_keyfile 

distinguished_name 

attributes 

x509 extensions 


2048 
sha256 
privkey.pern 

= req_distinguished_name 
req_attributes 
v3 ca 


[ req_distinguished_name ] 

countryName = Country Name (2 letter code) 

countryName_default = XX 

countryName_min = 2 

countryName_max = 2 


stateOrProvinceName 
#stateOrProvinceName default 


= State or Province Name (full name) 
= Default Province 


localityName 
localityName_default 


= Locality Name (eg, city) 
= Default City 


0.organizationName 
0.organizationName_default 


= Organization Name (eg, company) 
= Default Company Ltd 


organizationalUnitName = Organizational Unit Name (eg, section) 

#organizationalUnitName_default = 


commonName = Common Name (eg, your name or your server)'s hostname) 

commonName max = 64 


emailAddress = Email Address 

emailAddress max = 64 


94 



95 

The enterprise CA admin can then put these entries in the appropriate line in the configuration 

96 

file. For example: 


97 

[ req distinguished name ] 


98 

countryName 

= Country Name (2 letter code) 

99 

countryName default 

= US 

100 

countryName min 

= 2 


DNS-Based Email Security Practice Guide 


57 





Chapter 3. Device Configuration and Operating Recommendations 


101 

102 

103 

104 

105 

106 

107 

108 

109 

110 

111 

112 

113 

114 


countryName max 


= 2 


stateOrProvinceName = State or Province Name (full name) 

stateOrProvinceName default = District of Columbia 


localityName 


= Locality Name (eg, city) 


localityName default 


= Washington 


0 .organizationName = Organization Name (eg, company) 

0 .organizationName default = Department of Examples 

Once the default values are in place, the configuration file will be used unless overridden in the 
openssl command line. If the configuration file has been moved to a new directory, the 
command line option -config should be included in the openssl command to point to the 
location of the new configuration file location. 


H5 3.1.2.3 Using Linux Environment Variables to Dynamically Set Common Name and 
ii6 SubjectAltName 

in Not all of the values can be set via the command line override. The most important value that 

ns an enterprise CA admin may want to change is the SubjectAltName of a certificate. The 

ii9 SubjectAltName is used to provide alternative hostnames for a server that can be checked 

during PKIX validation. This allows one server to have multiple names and still use the same key 
pair for TLS. The SubjectAltName default can be set in the configuration file, but cannot be set 
122 at the command line. 


123 

124 

125 

126 

127 

128 

129 

130 

131 

132 

133 


On Linux systems, the following can be used in the configuration file to use environment 
variables for CommonName (called COMNAME) and SubjectAltName (called SAN). See below: 


commonName 
commonName default 
commonName max 


Common Name (eg 
${ENV::COMNAME} 
64 


your name or your 


subj ectAltName 


= ${ENV::SAN} 


After the changes have been made to the configuration file, the CommonName and 
SubjAltName can be set dynamically (either via command line or appropriate system call in 
scripts, programs, etc.) to set the entries before generating a certificate. 


134 3.1.3 Certificate Generation 

135 3.1.3.1 Generate the Root Certificate 

136 Once the configuration file is edited, the enterprise CA administrator must first generate a root 

137 certificate. This can be done using the openssl command line tool, or an included support script 

138 CA.pl. The following examples use the command line, as it is flexible and can be used via 

139 scripted system calls (that set environment variables, etc.). The basic command to generate a 

ho root certificate is: 
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141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 


>openssl 

-key 

-new 

-out 


req -config <config file> \ 
private/ca.key.pem \ 

-x 509 -days 7300 -sha 256 -extensions 
certs/ca.cert.pem 


v 3 ca 


\ 


Here the -config option is used to list the location of the configuration file in use. The use of the 
-days option is to increase the lifetime of the root cert over any default value in the 
configuration file. The root certificate is not like end-entity issued certificates and often 
requires more configuration possible manual installation in enterprise systems, so should be 
longer lived for administration purposes (and highly protected). Enterprise CA administrators 
should consult NIST SP 800-152, A Profile for U. S. Federal Cryptographic Key Management 
Systems for recommendations on how to set up a key management system. 


152 3.1.3.2 Generating Intermediate and End-Entity Certificates 

153 Once the CA infrastructure is set up and the root certificate is generated, the enterprise CA can 

154 start generating end-entity and (if desired) intermediate certificates. Intermediate certificates 

155 are just that: certificates that are extra "links" in the PKIX validation chain to the root certificate. 

156 They are not usually installed as trust anchors, but can be used to sign other (often end-entity) 

157 certificates. 

158 The advantage of using intermediate certificates is that they can be used to compartmentalize 

159 end-entity certificates, so a compromise of an intermediate cert means that only that 

160 certificate (and those it signed) are compromised, and not the entire CA. Intermediate 

1 6 1 certificates also allow CA administrators to keep the root certificate safely stored offline. Once 

162 the root key is used to sign the intermediate certificates, it can be stored offline until new 

163 intermediate certificates are needed. 

164 The disadvantages of using intermediate certificates is that they are needed by all clients 

165 wishing to do PKIX validation. If a client cannot find (or have stored) all necessary intermediate 

166 certificates, it cannot validate all end-entity certificates. Protocols like TLS account for this by 

167 having certificate chains available (end-entity and necessary intermediate certificates), but not 

168 all protocols do this. DANE is an option for publishing intermediate certificates in the DNS as 

169 intermediate certs, or as short-circuited trust anchors, depending on which Certificate Usage 

no (CU) parameter is used [RFC6698], 

1 7 1 The general command to generate a new client key pair and certificate is: 

172 >openssl req -new -nodes -config <config file> -keyout <key filename> 

173 -out \ 

174 <CSR filename> 

175 The above command will generate a key pair and a Certificate Signing Request (CSR) for the 

176 new certificate. The -nodes option disables the setting of a password for decrypting the private 

177 portion of the key pair. This is important to set for server certificates where there is no end user 

178 to enter a password (and the private key is needed to set up a TLS connection). For 

179 intermediate certificates, this should not be set, as that private key should be protected. 

180 Once the CSR is generated, it is made into a certificate: 

181 >openssl ca -config <config file> -out -infiles <CSR filename> -out 

182 <cert name> 
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183 

184 

185 

186 

187 

Then the administrator follows the prompt. Administrators using intermediate keys may also 
use the -key <private key> option to have openssl use the desired intermediate key. 
Alternatively, the administrator could configure the which signing key to use in the openssl 
configuration file. Indeed, several separate configuration files could be used if multiple 
intermediate keys are used for the enterprise CA. 

188 

189 

190 

191 

192 

Once the new certificate and key pair have been generated, they must be protected from 
unauthorized disclosure. They must be security communicated to server administrators so the 
administrators can configure them for use. Once the key has outlived its lifetime, it must be 
security retired and removed. These operations should be documented as part of the 
enterprise key management system. 

193 3.2 

Cryptographic Operations (User Actions) 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

204 

This section provides information regarding user actions necessary for users to invoke digital 
signature, encryption, and cryptographic certificate management features of Outlook and 
Thunderbird. The user's experience varies from relatively minimal additional impact in 
enterprise environments with established system administration and support to a significant 
impact in the case of individual self-supported users. Where the enterprise offers systems 
administration and support services, the user's experience with respect to DNS services is 
essentially unchanged. One exception is that, where DNS authentication fails, email messages 
sent to or by a user will not be delivered. This should be an uncommon experience for 
correspondents but it is up to the enterprise DNS administrator to prevent this happening. 
Similarly, for server-to-server encryption, the security protection features should be essentially 
transparent to the user. 

205 3.2.1 

Outlook 

206 

207 

To use digital signatures and encryption, both the sender and recipient must have a mail 
application that supports the S/MIME standard. Outlook supports the S/MIME standard. 

208 

209 

210 

211 

Instructions for user-driven cryptographic functions vary from version to version and platform 
to platform. Accessing digital signature on an Outlook Help page usually provides the necessary 
operator instructions. The example instructions provided here are for Outlook 2016 for 
Windows 10 and Outlook for Mac 2011. 

2123.2.1.1 

Outlook 2016 for Windows 10 

213 

214 

215 

216 

217 

218 

When a user has been issued an S/MIME certificate they can import it into the Outlook 2016's 
Trust Center to be used for digital signature and encryption based upon the key usages of the 
certificate. When a smart card containing a secure email digital signature certificate is inserted 
the Windows operating system, the OS will import the certificate into the user's personal 
certificate store. This will occur when the user inspects the smart card with the certutii.exe 
-scinfo command or if the following group policy is enabled: 

219 

220 

Computer Configuration -> Administrative Templates -> Windows Components -> Smart Card: 
Turn on certificate propagation from smart card 

221 

To view the certificates in the user's certificate store, type certmgr.msc. 
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222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 


239 


Configure Outlook 2106 S/MIME Settings: 

1. Open Outlook 2016. 

2. Click on File, and then Options. 

3. In the left-hand menu click on Trust Center. 

4. Click on the Trust Center Settings box. 

5. Click Email Security in the left-hand menu. 

6 . Click the Settings button within the Encrypted Email section. 

7. Enter a name within the Security Settings Name field. 

8 . Select the Signing Certificate by clicking on the Choose button for the signing certificate and 
select the Hash Algorithm. 

9. If you have an S/MIME encryption certificate select the Choose button for the encryption 
certificate and select the Encryption Algorithm. 

10. Select the radio button Send to send these certificates with signed messages. 

The user can choose to always digitally sign a message by selecting the Add digital signature to 
outgoing messages within the Trust Center -> Email Security -> Encrypted Email menu. This 
will digitally sign every outgoing email. To individually sign an email, within the draft message 
itself go to Options and within the Permissions menu select the Sign icon. 

D Encrypt 
Permission O sign 

Permission 


240 3.2.1.2 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 


Outlook for Mac 2011 Certificate Management 


If the user has a person's certificate in Outlook, he or she can validate a digitally signed 
message. 1 


E 


1. Importing a Certificate 

a. At the bottom of the navigation pane, click Contacts 

b. Open the desired contact, and then click the Certificates tab. 
Click 0 , locate the certificate, and then click Open. 


c. 


Note: To set the default certificate for a contact, select the certificate, click , and 
then click Set as Default. 

2. Exporting a Certificate 

Certificates can be exported in three formats: DER encoded X.509, PEM (Base-64 encoded 
X.509), and PKCS #7. The DER encoded X.509 format is the most common, but the user 
might want to ask what format his or her recipient requires. 


1. This also enables the user to send that person an encrypted message (user to user). 
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253 

254 

255 

256 

257 

258 

259 

260 

2613 . 2 . 1.3 

262 

263 

264 

265 

266 

267 

268 

269 

270 

271 

272 

273 

274 

275 

276 

277 

278 

279 

280 
281 


282 

283 


a. At the bottom of the navigation pane, click Contacts 

b. Open the desired contact, and then click the Certificates tab. 

c. Select the certificate, click , and then click Export . To set the format of the 
certificate, make a selection on the Format menu. 

3. Deleting a Certificate 

a. At the bottom of the navigation pane, click Contacts 

b. Open the desired contact, and then click the Certificates tab. 

c. Select the certificate, and then click H. 


[±J. 


Digital Signature 

To use digital signatures (or encryption), both the sender and recipient must have a mail 
application that supports the S/MIME standard. Outlook supports the S/MIME standard. 

Note: Before a user starts this procedure, he or she must first have a certificate added to the 
keychain on his or her computer. For information about how to request a digital certificate from a 
certification authority, see Mac Help. 

1. On the Tools menu, click Accounts. 

The user clicks the account from which he or she wants to send a digitally signed message, 
clicks Advanced, and then clicks the Security tab. 

2. Under Digital signing, on the Certificate pop-up menu, the user clicks the certificate that he 
or she wants to use. 

Note: The Certificate pop-up menu only displays certificates that are valid for digital 
(signing or encryption) that the user has already added to the keychain for his or her Mac 
OS X user account. To learn more about how to add certificates to a keychain, see Mac OS 
Help. 

3. To make sure that the user's digitally signed messages can be opened by all recipients, even 
if they do not have an S/MIME mail application and cannot verify the certificate, select the 

Send digitally signed messages as cleartext check box. 

4. Click OK, and then close the Accounts dialog box. 

5. In an e-mail message, on the Options tab, click Security, and then click Digitally Sign 
Message. 




Permissions 

Security 


6 . Finish composing the message, and then click Send. 
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2843.2.2 Thunderbird 1 

285 For purposes of illustration, the description of the user experience with Thunderbird also 

286 included certificate management requirements. The example here shows both S/MIME and 

287 PGP examples of certificate management. The S/MIME approach is recommended. Note that 

288 when using OpenPGP, a FIPS 140-conformant version should always be used. 


289 3.2.2.1 S/MIME Certificate Management 


290 S/MIME certificates are used for digitally signed and encrypted e-mail messages. For 

291 information about getting or creating S/MIME certificates, see: 

292 http://kb.mozillazine.org/Getting_an_SMIME_certificate. 

293 1. Installing an S/MIME certificate 

Important: Before a user can create or import his or her own certificate and private key, he 

295 or she must first set a master password if this has not already been done. The master 

296 password is needed so that imported certificates are stored securely. See 

297 http://kb.mozillazine.org/Master_password for instructions for setting a master password. 

298 The user may have his or her own personal certificate and private key in a ,pl2 or .pfx file, 

299 and may wish to import it into Thunderbird. Once a Master Password has been set, the user 

300 can import/install a personal S/MIME certificate from a ,pl2 or .pfx file by doing the 

301 following steps. 


302 a. Open the Certificate Manager by going to Tools -> Options... -> Advanced -> 

303 Certificates -> Manage Certificates.... 


304 


b. Go to the tab named Your Certificates. 


305 c. Click on Import. 

306 d. Select the PCKS12 certificate file (.pfx or .p!2). 


307 e. It will ask the user for the master password for the software security device. The user 

308 enters his or her master password and clicks OK. 


309 

310 

311 


f. Next, it will ask the user for the password protecting his or her personal certificate. If 
the user's ,pl2 or .pfx file has a password, the user enters it here, otherwise leave this 
field empty. The user then clicks OK. 


312 

313 

314 


The S/MIME certificate should now have been imported. If the certificate was not 
trusted, consult the instructions at 

http://kb.mozillazine.Org/Thunderbird_:_FAQs_:_lmport_CA_Certificate. 


315 2. Configuring Thunderbird for using the certificate to sign email 


316 Go to Tools -> Account Settings... in ThunderBird. Then find the account with the email 

317 address that matches the email address in the certificate that has just been installed. The 

318 user chooses Security under that account and selects the certificate that has just been 

319 installed. The rest of the options should be self explanatory. When the user selects a 

320 certificate in Account Settings, that selection only applies to the account's default identity 

321 or identities. There is no user interface for specifying certificates for an account's other 


1. See https://support.mozilla.org/en-US/kb/digitally-signing-and-encrypting-messages 
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322 

323 

324 

325 

326 

327 

328 

329 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 3.2.2.2 

361 

362 

363 

364 


identities. If desired, this can be worked around by editing the settings manually, copying 
the settings from an account's default identity to some other identity. The settings have 
names ending in: signing_cert_name, sign_mail, encryption_cert_name, and 
encryptionpolicy. 

3. User Installation of a Self-Signed S/MIME Certificate 

If the SMIME certificate in a user's ,pl2 or .pfx file is a self-signed certificate for the user's 
own identity, then before that file can be installed into the tab named Your Certificates, the 
user must first install that certificate as a certificate authority in the Authorities tab. The 
PKCS12 certificate file will not install into the Authorities tab. The user will need a copy of a 
self-signed certificate that does not contain the user's private key. This is usually in the form 
of a .cer file. One way to obtain the .cer form of a certificate from the ,pl2 file is to use the 
Firefox Add-on Key Manager to extract the .cer certificate from the ,pl2 file. With that 
Add-on installed in Thunderbird, the user goes to Tools -> Key Manager Toolbox -> Key 
Manager -> Your Keys, selects his or her key, selects Export and chooses X.509 as file 
format. 

a. Go to Tools -> Options... -> Advanced -> Certificates -> Manage Certificates.... 

b. Go to the Authorities tab. 

c. Click on Import. 

d. Select the .cer file. 

e. It will ask the user for what purposes he or she wants to trust the certificate. The user 
selects Trust this CA to identify email users. 

f. Click OK to complete the import. 

Note: Thunderbird automatically adds other people's S/MIME certificates to the Other People's 
tab of a user's Certificate Manager when he or she receives from them a digitally signed 
message with a valid signature and with an S/MIME certificate issued by a recognized and 
trusted Certificate Authority (CA). CA certificates that appear in ThunderBird's Authorities tab 
are recognized, and may also be trusted. CA certificates that do not appear in that tab are 
considered unrecognized. An S/MIME certificate that was issued by an unrecognized CA will 
not be automatically added to the Other People's tab of the user's Certificate Manager. If the 
user attempts to manually import an S/MIME certificate that was issued by an unrecognized CA, 
nothing will happen-literally. Thunderbird will not even display an error dialog. It will just not 
import the S/MIME certificate. This is generally not a problem when receiving an S/MIME 
certificate that was issued by a trusted Certificate Authority (CA), but could be a problem for a 
certificate that was issued by an unrecognized or untrusted CA, or for a certificate that is 
self-signed (i.e. it has no CA other than itself). So, before a user can import an S/MIME 
certificate that is issued by an unrecognized CA or is self-signed, he or she must first acguire 
and import the certificate for the issuing CA. In the case of a self-signed certificate, a .cer file 
needs to be acguired from the individual whose certificate the user wishes to add. 

PGP Example of Sending and Receiving Public Keys 

1. Sending a public key via email 

To send signed messages to other people that the recipients can validate, the user must first 
send them the public key: 

a. Compose the message. 
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365 


366 


b. Select OpenPGP from the Thunderbird menu bar and select Attach My Public Key. 


Write: (no subject) 

File Edit View Options 
Mi Sen d J V' Spelling 
From: | 

To: 



V Sign Message 
Encrypt Message 

Use PGP/MIME for This Message 


Subject 


✓ 


Key Management 
Undo Encryption 
Attach My Public Key 

Help 


367 

368 

369 

370 

371 

372 

373 

374 


375 


c. Send the email as usual. 

2. Receiving a public key via email 

To verify signed messages from other people, the public key must be received and stored: 

a. Open the message that contains the public key. 

b. At the bottom of the window, double click on the attachment that ends in .asc. (This file 
contains the public key.) 

c. Thunderbird automatically recognizes that this is a PGP key. A dialog box appears, 
prompting the Import or View of the key. Click Import to import the key. 



376 

377 

378 

379 

380 

381 

382 


383 


d. A confirmation that the key has been successfully imported will be shown. Click OK to 
complete the process. 

3. Revoking a key 

If the private key may have been "compromised" (that is, someone else has had access to 
the file that contains the private key), revoke the current set of keys as soon as possible and 
create a new pair. To revoke the current set of keys: 

a. On the Thunderbird menu, click OpenPGP and select Key Management. 


File Edit View Go Message 

OpenPGP] lools Help 

£ Get Mail - f Write 

A 

Save Decrypted Message 

abhishek...ail.com 

i^i Inbox 

Th 

Preferences 

Key Management 

1 i Drafts 

Sent 

__ Deleted 

mike.ros...ail.com 


E 

Help 

Setup Wizard 

About OpenPGP 

i^i Inbox 

L_| Drafts 


Ls<i 

Read messages 

H, Sent 





ecr 

ik 




DNS-Based Email Security Practice Guide 


65 














































Chapter 3. Device Configuration and Operating Recommendations 


384 

385 

386 

387 

388 

389 

390 

391 

392 

393 

394 

395 3.2.2.3 

396 

397 

398 


399 

400 

401 

402 

403 

404 3.2.2.4 

405 

406 

407 

408 

409 

410 


b. A dialog box appears as shown below. Check Display All Keys by Default to show all the 
keys. 

c. Right-click on the key to be revoked and select Revoke Key. 

d. A dialog box appears asking the user if he or she really want to revoke the key. Click 

Revoke Key to proceed. 

e. Another dialog box appears asking for the entry of a secret passphrase. Enter the 
passphrase and click OK to revoke the key. 


The user sends the revocation certificate to the people with whom he or she corresponds so 
that they know that the user's current key is no longer valid. This ensures that if someone tries 
to use the current key to impersonate the user, the recipients will know that the key pair is not 
valid. 


Sending a Digitally Signed Email 

1. Compose the message as usual. 

2. To digitally sign a message, select OpenPGP from the Thunderbird menu and enable the 
Sign Message option. 


Cl 


Write: (no subject) 


File Edit View Options 

OpenPGP) Tools Help 

[ Ml Send || / Spelling 

V 

Sign Message 


From: 

To: 


Mike F 


Subject 


Encrypt Message 
Use PGP/MIME for This Message 

Key Management 
Undo Encryption 
Attach My Public Key 

Help 



3. If the email address is associated with a cryptographic certificate, the message will be 
signed with the key contained in that certificate. If the email address is not associated with 
a cryptographic certificate, a certificate must be selected from a list. 

4. Send the message as usual. 


Reading a Digitally Signed Email 

When a signed message is received, and If Thunderbird recognizes the signature, a green bar 
(as shown below) appears above the message. 

To determine whether or not the incoming message has been signed, look at the information 
bar above the message body. 1 

Key ID. 0>fi0f92106 / $qr*d «* V2S/2012 4:27 PM 


If the message has been signed, the green bar also displays the text, "Signed message". 


1. If the message is also encrypted on a user to user basis, Thunderbird will also ask for the entry 
of a secret passphrase to decrypt the message. 
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411 

412 


A message that has not been signed could be from someone trying to impersonate someone 
else. 


413 


3.3 Server-to-Server Encryption Activation and Use 


414 3.3.1 Office 365 Exchange 

Server-to-server encryption (Scenario 1) is available on Exchange for Office 365. Office 365 

416 encrypts users' data while it's on Microsoft servers and while it's being transmitted between 

417 the user and Microsoft. Office 365 provides controls for end users and administrators to fine 

418 tune what kind of encryption is desired to protect files and email communications. Some 

419 technical library links for specific topics are as follows: 

420 ■ Information on encryption using Office 365 Exchange can be found at 

421 https://technet.microsoft.com/en-us/library/dn569286.aspx. 

■ Information regarding the different types of email encryption options in Office 365 

423 including Office Message Encryption (OME), S/MIME, Information Rights Management 

424 (IRM) can be found at https://technet.microsoft.com/en-us/library/dn948533.aspx. 

425 ■ Information regarding definition of rules regarding email message encryption and 

426 decryption can be found at https://technet.microsoft.com/en-us/library/dn569289.aspx. 

427 ■ Information regarding sending, viewing, and replying to encrypted messages can be found 

428 at https://technet.microsoft.com/en-us/library/dn569287.aspx. 

429 ■ Service information for message encryption can be found at 

430 https://technet.microsoft.com/en-us/library/dn569286.aspx. 


431 


3.3.2 Postfix 


432 

433 


Postfix TLS support is described at http://www.postfix.org/TLS_README.html. Postfix can be 
set to encrypt all traffic when talking to other mail servers. 1 


434 


435 

436 


3.4 Utilities and Useful Tools 

This section provides links to some tools and utilities that are useful in installing, configuring, 
provisioning, and maintaining DNS-based email security software. 


1. "Setting Postfix to encrypt all traffic when talking to other mailservers," Snapdragon Tech 
Blog, August 9, 2013. http://blog.snapdragon.cc/2013/07/07/setting-postfix-to-encrypt-all-traf- 
fic-when-talking-to-other-mailservers/ 
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437 3.4.1 

DANE Tools 

4383.4.1.1 

SMIMEA Retriever Tool 

439 

440 

441 

442 

443 

The SMIMEA retriever tool, developed by Santos Jha as part of this project, retrieves SMIMEA 
records from a DNS for a given email address and stores the certificates in PKCS12 format. This 
PKCS12 store can subsequently be imported into an MUA such as Thunderbird or Outlook. Since 
this software is used for offline provisioning of certificates, the developer focused on selector=0 
and matching type=0. It is written using Java 8. 

444 3.4.1 .2 

TLSA Generator 

445 

446 

447 

Shumon Huque's online TLSA generator generates TLSA resource records from a certificate and 
parameters for which prompts are included. The link to the tool is 

https://www.huque.com/bin/gen_tlsa. 

448 3.4.1 .3 

High Assurance Domain Toolbox 

449 

450 

451 

452 

NIST's High Assurance Domain Toolbox is a collection of perl scripts used to generate and 
format SMIMEA and TLSA RR's for use with the High Assurance Testbed. Each of these scripts 
are used independently and not all required to be used if other solutions work better. The tool 
can be found at https://github.com/scottr-nist/HAD-tlsa-toolbox. 

453 3.4.1.4 

Swede 

454 

455 

Swede is a tool for use in creating and verifying DANE records. The tool can be found at 

https://github.com/pieterlexis/swede. 

456 3.4.1 .5 

Hash-slinger 

457 

458 

459 

460 

Hash-slinger is a package of tools created by Paul Wouters of RedHat to make it easy to create 
records for the DANE protocol that will allow you to secure your SSL/TLS certificates using 
DNSSEC. The package is available for Linux at: 

http://people.redhat.com/pwouters/hash-slinger/. 

461 3.4.2 

DANE Validation Sites and Testers 

462 3.4.2.1 

NIST DANE Testers 

463 

464 

NIST's DANE-testers for RFC 6698 conformance can be found at 

http://dane-test.had.dnsops.gov/. 

465 3.4.2.2 

SMIMEA Test Tool 

466 

Grier Forensics' SMIMEA Test tool can be found at http://dst.grierforensics.eom/#/start. 
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467 3.4.2.3 

DANE Validator Online Test Tool 

468 

469 

470 

471 

The DANE validator online test tool found at https://check.sidnlabs.nl/dane/ attempts to 
perform validation of a TLSA/PKI pair according to the DANE Internet standard. Note that the 
tool automatically selects Port 443 and TCP. SNI support is included. The tool set uses the 
Idns-dane example from LDNS from NLnet Labs. 

472 3.4.2.4 

DANE SMTP Validator 

473 

The DANE SMTP Validator, an SMTP DANE test tool, can be found at https://dane.sys4.de/. 

4743.4.3 

Other Test Tools 

475 

476 

477 

478 

479 

DNSViz is a tool for visualizing the status of a DNS zone. It was designed as a resource for 
understanding and troubleshooting deployment of the DNS Security Extensions (DNSSEC). It 
provides a visual analysis of the DNSSEC authentication chain for a domain name and its 
resolution path in the DNS namespace, and it lists configuration errors detected by the tool. 
This DNSSEC test tool is not DANE specific, but helpful. It can be found at http://dnsviz.net/. 
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Acronyms 

2 ASN 

Abstract Syntax Notation 

3 AXFR 

DNS Full Zone Transfer Query Type 

4 BIND 

Berkeley Internet Name Daemon 

s BSD 

Berkeley Software Distribution 

6 CA 

Certificate Authority 

7 CRL 

Certificate Revocation List 

b CSR 

Certificate Signing Request 

9 CU 

Certificate Usage Type 

io DANE 

DNS-based Authentication of Named Entities 

ii DNS 

Domain Name System 

,2 DNSSEC 

DNS Security Extensions 

i3 Email 

Electronic Mail 

,4 FIPS 

Federal Information Processing Standard 

, s GAL 

Global Address List 

,0 HTTP 

Flypertext Transfer Protocol 

„ IETF 

Internet Engineering Task Force 

,8 IMAP 

Internet Message Access Protocol 

„ IP 

Internet Protocol 

20 ITL 

Information Technology Laboratory 

2, LDAP 

Lightweight Directory Access Protocol 

22 MIME 

Multipurpose Internet Mail Extension 

23 MTA 

Mail Transfer Agent 

24 MUA 

Mail User Agent 

25 MX 

Mail Exchange (Resource Record) 

20 NCCoE 

National Cybersecurity Center of Excellence 

2, NIST 

National Institute of Standards and Technology 

28 NSD 

Network Server Daemon 

2, OS 

Operating System 

30 PKI 

Public Key Infrastructure 

3, PKIX 

Public Key Infrastructure X.509 

32 POP 

Post Office Protocol 

33 RFC 

Request for Comments 
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34 

RMF 

Risk Management Framework 

35 

RR 

Resource Record 

36 

S/MIME 

Secure/Multipurpose Internet Mail Extensions 

37 

SMIMEA 

S/MIME Certificate Association (Resource Record) 

38 

SMTP 

Simple Mail Transfer Protocol 

39 

SP 

Special Publication 

40 

SQL 

Structured Query Language 

41 

TLS 

Transport Layer Security 

42 

TLSA 

TLS Certificate Association (Resource Record) 

43 

UA 

User Agent 

44 

VLAN 

Virtual Local Area Network 

45 

VM 

Virtual Machine 
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Appendix C Platform Operation and 
Observations 


,C.1 Operations Scenarios 

4 Both server-to-server encryption (Scenario 1) and user signature (Scenario 2) of electronic mail 

s are demonstrated. Demonstrations of the security platform include attempts by fraudulent 

i actors to pose as the originator of email and man-in-the-middle attackers attempting to disrupt 

7 the validation the S/MIME signature. Events are included that involve all components and 

b demonstrate that each of the MUAs can be used with both MTAs, and both MTAs can run with 

» each of the four DNS stacks. Use of self-signed certificates and of certificates from local and 

io well-known certificate authorities are included. The events do not cover all possible 

combinations of components for both mail origination and receipt, but they do include 
12 demonstration of both Exchange and Postfix as senders, all four DNS services, and both 

is Exchange and Postfix as recipients accessed by both Outlook and Thunderbird MUAs. For each 

14 event identified below, we identify the components involved, operator actions required by both 

is the sender and the receiver, and observed results. For purposes of avoiding excessive repetition 

i 6 in test events, each event includes demonstration of both scenarios. 

„ C.1.1 Server-to-Server Encrypted Email in Scenario 1 

is An individual needed to enter into an email exchange with an individual in another organization 

19 that required protected transfer of information. Each individual exchanged email via the 

20 respective parent organizations' mail servers. Users connected to their organizations' respective 

21 mail servers within a physically protected zone of control. 

22 The policy of the parent organizations required encryption of the information being exchanged. 

23 The security afforded by the cryptographic process was dependent on the confidentiality of 

24 encryption keys from unauthorized parties. The mail servers were configured to use X.509 

25 certificates to convey keying material during an encryption key establishment process. 

26 DNSSEC was employed to ensure that each sending mail server connected to the legitimate and 

27 authorized receiving mail server from which its X.509 certificate was obtained. DANE resource 

2 a records were employed to bind the cryptographic keying material to the appropriate server 

29 name. STARTTLS was employed to negotiate the cryptographic algorithm to be employed with 

30 TLS in the email exchange in which the message was transferred. Encryption of the email 

3 1 message was accomplished by the originator's email server, and decryption of the email 

32 message was accomplished by the recipient's email server. 


33 C.I .2 Signed Email in Scenario 2 

34 Scenario 2 supports the case of an individual needing to enter into an exchange of email that 

35 requires integrity protection with an individual in another organization that. Each individual 

36 exchanged email via the respective parent organizations' mail servers. Users connected to their 

37 organizations' respective mail servers within a physically protected zone of control. 
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The policies of the parent organizations required cryptographic digital signature of the message 
to provide integrity protection and source authentication of the email message. S/MIME is a 
widely available and used protocol for digitally signing electronic mail. Each organization 
therefore generated X.509 certificates for their users that included the public portion of their 
signature keys. These certificates were then published in the DNS using the appropriate DANE 
DNS Resource Record (RR) type. 

DNSSEC was used to provide assurance that the originating user's mail server connected to the 
intended recipient's mail server. DANE records were employed to bind the cryptographic 
certificates to the appropriate server (for TLS) and individual user (for S/MIME), respectively. 
TLS was employed to provide confidentiality. Digital signature of the email message was 
accomplished by the originator's email client. Validating the signature (hence the integrity of 
the authorization provided in the email message) was accomplished by the recipient's email 
client. 


C.1.3 Handling of Email from Fraudulent Sender 

Demonstrations of the security platform in both scenarios included an attempt by a fraudulent 
actor to pose as the originator of the email. Where it was implemented, DANE was used to 
expose the fraudulent originator's attempt. 

C.1.4 Handling of Man-in-the-Middle Attack 

Demonstration of the security platform in both scenarios also included a man-in-the-middle 
attacker attempting to disrupt the validation of the S/MIME signature. Where DANE was 
implemented, the attempts were shown to fail due to use of DNSSEC and DANE records. 

C.1.5 Effects of DNS Errors 

A DANE-enabled Postfix MTA sent message traffic to four Exchange MTAs with one 
Authoritative Server serving all four zones. An NSD4 Authoritative DNS server and Unbound 
recursive server was provided for the Postfix MTA, and a Secure64 DNS Authority and Signer 
provided the DNS services for the Exchange zones. 


C.2 Test Sequences 

The test and demonstration events selected were chosen to demonstrate the functionality 
available in both scenarios, the effectiveness of available DNS services, and the interoperability 
of components. The event selection objectives also included keeping the events to a 
manageable number, while capturing significant performance information. As a result, several 
stacks of contributed MUA, MTA, and DNS service components were demonstrated in the 
NCCoE laboratory environment, and representative NCCoE laboratory configurations were 
shown exchanging email with two different external sites using several cryptographic certificate 
types (certificates from Well-Known CAs (with TLSA RR cert usage (CU) of 1), Enterprise CAs 
(with TLSA RR cert usage of 2), and Self-Signed CAs (with TLSA RR cert usage of 3). The first 
external site used Secure64 DNS services, a Postfix MTA, and a Thunderbird MUA with an Apple 
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Keychain Utility. The second external site used NLnet Labs DNS services, a Postfix MTA, and a 
Thunderbird MUA. 


C.2.1 Test Sequence 1: MUA/MTA/DNS Service Combinations 

Exchanged Signed and Encrypted Email with a Secure64 Site and 
an NLnet Labs Site 

An Outlook MUA, interfacing with an Exchange MTA, was configured to use Active Directory 
and BIND DNS services in turn. Each of the six configurations exchanged email with 1) a 
Secure64 MUA/MTA/DNS service stack that included a Postfix MTA and a Thunderbird MUA 
running on a Mac OS System, and 2) an NLnet Labs MUA/MTA/ DNS service stack that included 
a Postfix MTA and a Thunderbird MUA running on Linux. The events include events showing use 
of Well-Known CAs (CU-1), Enterprise CAs (CU=2), and Self-Signed Certificates (CU=3) for TLS 
and S/MIME-enabled mail receivers and S/MIME. Digital signature of the messages was logged. 
All messages were S/MIME signed. Outlook attempted to verify received messages (Scenario 2). 
Signature verification results were noted. DNS name verification results were noted. Figure 2.1 
above depicts the set-up for laboratory support for the Secure64 destination variant of this test 
sequence. 1 

C.2.1.1 Active Directory and DNS Server in NCCoE Laboratory 

The Active Directory, DNS Server, an Exchange MTA, and an Outlook MUA were configured with 
appropriate certificates for each deployment scenario. These certificate policies include S/ 
MIME and TLS certificates from a Well-Known CA, certificates from an Enterprise CA, and self- 
signed certificates (using TLSA and SMIMEA parameters CU=1, CU=2, and CU=3 respectively). 
Each of these three variations sent S/MIME signed and TLS encrypted email to a Secure64 site 
and an NLnet Labs site. The Secure64 site was using a MacBook-hosted Thunderbird MUA, a 
Postfix/Dovecot MTA, DNS Cache/DNS Authority services for processing received messages, 
and DNS Signer for outbound messages. The NLnet site was using an Intel-hosted Thunderbird 
MUA, a Postfix/Dovecot MTA, NSD4 and Unbound for processing received messages, and 
OpenDNSSEC for outbound messages. Each of the events included the NCCoE Laboratory 
configuration sending a signed and encrypted message to the remote sites, and a signed 
response being sent from each remote site to the NCCoE configuration. 

1. Event 1: Outlook MUA Using an Exchange MTA using Well-Known CA issued Certificates for 
TLS and S/MIME 

Expected Outcome: NCCoE Outlook MUA sent a test message in an S/MIME signed email 
using Active Directory DNS Services and a Well-Known CA (CU=1) to Secure 64 and NLnet 
Labs, and both recipients returned responses that were S/MIME signed. The signature for 
the received messages was verified. 

Observed Outcome: As expected, the messages were authenticated and a log file was 
saved. 

2. Event 2: Outlook MUA Using an Exchange MTA using Enterprise CA issued Certificates for 
TLS and S/MIME 


1. The connections depicted in Figure 2.1 are actually for the first Sequence 2 configuration. Ca¬ 
pabilities for Sequence 1 support are shown as dotted lines. 
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Expected Outcome: NCCoE Outlook MUA sent a test message in an S/MIME signed email 
using Active Directory DNS Services and an Enterprise CA (CU=2) to Secure 64 and NLnet 
Labs, and both recipients returned responses that were S/MIME signed. The signature for 
the received messages was verified. 

Observed Outcome: As expected, the messages were authenticated and a log file was 
saved. 

3. Event 3: Outlook MUA Using an Exchange MTA using Self-Signed Certificate for TLS and S/ 
MIME 

Expected Outcome: NCCoE Outlook MUA sent a test message in an S/MIME signed email 
using Active Directory DNS Services and a self-signed TLS certificate (CU=3) to Secure 64 
and NLnet Labs, and both recipients returned responses that were S/MIME signed. The 
signature for the received messages was verified. 

Observed Outcome: As expected, the message was authenticated and a log file was saved. 

C.2.1.2 BIND in NCCoE Laboratory 

The BIND DNS Server, an Exchange MTA, and an Outlook MUA were configured with 
appropriate certificates for each deployment scenario. These certificate policies include S/ 
MIME and TLS certificates Well-Known CA, certificates from an Enterprise CA, and self-signed 
certificates (TLSA/SMIMEA parameters CU=1, CU=2, and CU=3 respectively). Each of these 
three variations sent S/MIME signed and TLS encrypted email to a Secure64 site and an NLnet 
Labs site. The Secure64 site was using a MacBook-hosted Thunderbird MUA, a Postfix/Dovecot 
MTA, DNS Cache/DNS Authority services for processing received messages, and DNS Signer for 
outbound messages. The NLnet site was using an Intel-hosted Thunderbird MUA, a Postfix/ 
Dovecot MTA, NSD4 and Unbound for processing received messages, and OpenDNSSEC for 
outbound messages. Each of the events included the NCCoE Laboratory configuration sending a 
signed message to the remote sites, and a signed response being sent from each remote site to 
the NCCoE configuration. 

1. Event 4: Outlook MUA Using an Exchange MTA using Well-Known CA issued Certificates for 
TLS and S/MIME 

Expected Outcome: NCCoE Outlook MUA sent a test message in an S/MIME signed email 
using a BIND DNS Server and Well-Known CA (CU=1) issued certificates to Secure64 and 
NLnet Labs, and both Secure64 and NLnet Labs returned a response that was S/MIME 
signed. The signature for the received messages was verified. 

Observed Outcome: As expected, the message was authenticated and a log file was saved. 

2. Event 5: Outlook MUA Using an Exchange MTA using an Enterprise CA issued Certificates for 
TLS and S/MIME 

Expected Outcome: NCCoE Outlook MUA sends a test message in an S/MIME signed email 
using a BIND DNS Server and an Enterprise CA (CU=2) issued certificates to Secure64 and 
NLnet Labs, and both Secure64 and NLnet Labs returned a response that was S/MIME 
signed. The signature for the received messages was verified. 

Observed Outcome: As expected, the message was authenticated and a log file was saved. 

3. Event 6: Outlook MUA Using an Exchange MTA using Self-Signed Certificates for TLS and S/ 
MIME 
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Expected Outcome: NCCoE Outlook MUA sent a test message in an S/MIME signed email 
using a BIND DNS Server and self-signed certificates (CU=3) to Secure64 and NLnet, and 
both Secure64 and NLnet returned a response that was S/MIME signed. The signature for 
the received messages was verified. 

Observed Outcome: As expected, the message was authenticated and a log file was saved. 


,„,C.2.2 Test Sequence 2: MUA/MTA/DNS Service Combinations 
.« Exchanged Signed and Encrypted Email with an NLnet Labs Site 

... and a Secure64 Site 

i«4 Outlook and Thunderbird MUAs, configured to use a Postfix MTA with Dovecot IMAP support, 

165 were configured in turn to use BIND and Secure64's DNS Authority, DNS Cache, and DNS Signer 

166 implementations. Each of the six configurations exchanged email with a Secure64 site that 

16 / included a Thundebird MUA, DNS Cache/DNS Signer/DNS Authority DNS services, and Postfix/ 

168 Dovecot MTA and an NLnet Labs MUA/MTA/ DNS service stack that included a Thundebird 

169 MUA, NSD4, Unbound, and OpenDNSSEC DNS services and a Postfix/Dovecot MTA. The test 

170 events include using Well-Known CA issued (TLSA/SMIMEA CU=1), Enterprise CA issued (CU=2), 

171 and Self-Signed Certificates (CU=3). Email messages between MTAs were encrypted and 

172 successfully decrypted. (Scenario 1). Signature and encryption were logged. All messages were 

1 73 S/MIME signed. Outlook attempted to verify received messages (Scenario 2). Signature 

1 74 verification results were noted. DNS name verification results were noted. Figure 2 above 

175 depicts the set-up for laboratory support for this test sequence, with connections selected for 

176 Event 7 below. 


177 C. 2.2.1 BIND and Postfix/Dovecot in NCCoE Laboratory 

178 Outlook, then Thunderbird mail clients were configured to use Postfix/Dovecot MTAs and BIND 

179 DNS servers. Each of these three configurations sent S/MIME signed and TLS encrypted email to 

iso a Secure64 site and an NLnet Labs site. The Secure64 site was using a Thunderbird MUA using 

1 8 1 Secure64's Apple Key Chain Utility tool that allows a host to obtain X.509 certificates via of 

1 82 DANE RRs, DNS Cache/DNS Signer/DNS Authority DNS services, and a Postfix/Dovecot MTA for 

183 mail. The NLnet Labs site was using a Thunderbird MUA, a Postfix/Dovecot MTA, and NSD4, 

184 Unbound, and OpenDNSSEC DNS Services. Each of the three events included the NCCoE 

185 Laboratory configuration sending a S/MIME signed and TLS encrypted message to the Secure64 

1 86 and NLnet Labs sites, and signed and encrypted responses being sent from the Secure64 and 

is? NLnet Labs site to the NCCoE. 


1. Event 7: Outlook MUA Using a Postfix/Dovecot MTA and Well-Known CA Issued Certificates 
for TLS and S/MIME 

Expected Outcome: NCCoE Outlook MUA using BIND for DNS sent a test message in an S/ 
MIME signed email to Secure64 and NLnet Labs. Secure64 and NLnet Labs returned 
responses that were S/MIME signed and TLS encrypted. The received messages were 
successfully decrypted, and the signatures were verified. All S/MIME and MTA TLS 
certificates in this test were issued from a well-known CA and TLSA/SMIMEA RR Certificate 
Usage parameter set to 1. 

Observed Outcome: As expected, the message was authenticated and decrypted, and a log 
file was saved. 
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2. Event 8: Thunderbird MUA Using a Postfix/Dovecot MTA and Enterprise CA Issued 
Certificates for TLS and S/MIME 


Expected Outcome: NCCoE Thunderbird MUA using BIND for DNS sent a test message in an 
S/MIME signed email to Secure64 and NLnet Labs. Secure64 and NLnet Labs returned 
responses that were S/MIME signed and TLS encrypted. The received messages were 
successfully decrypted, and the signatures were verified. All S/MIME and MTA TLS 
certificates in this test were issued from an enterprise local CA and TLSA/SMIMEA RR 
Certificate Usage parameter set to 2. 

Observed Outcome: As expected, the message was authenticated and decrypted, and a log 
file was saved. 


3. Event 9: Thunderbird MUA Using a Postfix/Dovecot MTA and Self-Signed Certificates 

Expected Outcome: NCCoE Thunderbird MUA using BIND for DNS sent a test message in an 
S/MIME signed email to Secure64 and NLnet Labs. Secure64 and NLnet Labs returned 
responses that were S/MIME signed and TLS encrypted. The received messages were 
successfully decrypted, and the signatures were verified. All S/MIME and MTA TLS 
certificates in this test were self-signed and TLSA/SMIMEA RR Certificate Usage parameter 
set to 3. 


Observed Outcome: As expected, the message was authenticated and decrypted, and a log 
file was saved. 


2,7 C.2.2.2 Postfix/Dovecot with DNS Authority, DNS Cache, and DNS Signer in NCCoE 
218 Laboratory 

2,9 A Thunderbird client was configured to use DNS Authority, DNS Cache, and DNS Signer Servers 

220 and use a Postfix/Dovecot MTA. Each of these three configurations sent S/MIME signed and TLS 

22 , encrypted email to a Secure64 site and an NLnet Labs site. The Secure64 site was using a 

222 Thunderbird MUA that employed Secure64's Apple Key Chain Utility tool that allows a host to 

223 obtain X.509 certificates via of DANE RRs, DNS Cache/DNS Signer/DNS Authority DNS services, 

224 and a Postfix/ Dovecot MTA for mail. The NLnet Labs site was using a Thunderbird MUA, a 

225 Postfix/Dovecot MTA, and NSD4, Unbound, and OpenDNSSEC DNS Services. Each of the three 

22 o events included the NCCoE Laboratory configuration sending an S/MIME signed and TLS 

227 encrypted message to the Secure64 and NLnet Labs sites, and signed and encrypted responses 

22 a being sent from the Secure64 and NLnet Labs site to the NCCoE. 


1. Event 10: Thunderbird MUA Using a Postfix/Dovecot MTA and Well-Known CA Issued 
Certificates for TLS and S/MIME 

Expected Outcome: NCCoE Thunderbird MUA using DNS Authority/Cache/Signer DNS 
Services and a Postfix MTA sent a test message in an S/MIME signed email to Secure64 and 
NLnet Labs. Secure64 and NLnet Labs returned that a message that we had S/MIME signed 
and TLS encrypted. The received messages were successfully decrypted, and the signatures 
were verified. All certificates in this test were issued from a well-known CA and TLSA/ 
SMIMEA RR Certificate Usage parameter set to 1. 

Observed Outcome: As expected, the message was authenticated and decrypted, and a log 
file was saved. 


2. Event 11: Thunderbird MUA Using a Postfix/Dovecot MTA and Enterprise CA Issued 
Certificates for TLS and S/MIME 
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Expected Outcome: NCCoE Thunderbird MUA using DNS Authority/Cache/Signer DNS 
Services and a Postfix MTA sent a test message in an S/MIME signed email to Secure64 and 
NLnet Labs. Secure64 and NLnet Labs returned a message that we had S/MIME signed and 
TLS encrypted. The received messages were successfully decrypted, and the signatures 
were verified. All certificates in this test were issued from an enterprise CA and TLSA/ 
SMIMEA RR Certificate Usage parameter set to 2. 

Observed Outcome: As expected, the message was authenticated and decrypted, and a log 
file was saved. 


3. Event 12: Thunderbird MUA Using a Postfix/Dovecot MTA and Self-Signed Certificates for 
TLS and S/MIME 

Expected Outcome: NCCoE Thunderbird MUA using DNS Authority/Cache/Signer DNS 
Services and a Postfix MTA sent a test message in an S/MIME signed email to Secure64 and 
NLnet Labs. Secure64 and NLnet Labs returned a message that we had S/MIME signed and 
TLS encrypted. The received messages were successfully decrypted, and the signatures 
were verified. All certificates in this test were self-signed and TLSA/SMIMEA RR Certificate 
Usage parameter set to 3. 

Observed Outcome: As expected, the message was authenticated and decrypted, and a log 
file was saved. 


25 ,C. 2.3 Sequence 3 : Fraudulent DNS Address Posing as Valid DNS 
Address Contacting Recipient MTAs 

26 1 Fraudulently S/MIME signed email was sent from a malicious sender to recipients using 

262 Outlook and Thunderbird MUAs configured to use Exchange and Postfix as MTAs. The Outlook/ 

263 Exchange configuration used Active Directory as its DNS server. The configurations employing 

264 Postfix/Dovecot MTAs were demonstrated with each of the other three contributed DNS 

265 Services. In one event, the Thunderbird MUA employed an Apple Key Chain Utility tool that 

266 allows a host to obtain X.509 certificates via of DANE RRs. All events were conducted using well- 

267 known CA and Enterprise CA-issued certificates for the impersonated sender. The fraudulent 

268 site attempted to spoof a valid sending domain belonging to a Secure64 site that was 

269 configured with DNS Authority/Cache/Signer DNS services, a Postfix/Dovecot MTA, and 

270 Thunderbird 1 equipped with the Apple Key Chain utility. An Outlook/Exchange/Active Directory 

271 set-up acted as the fraudulent site. The email exchange between organizations was carried over 

272 TLS, and the email message was S/MIME signed on the fraudulent users' client device. The set- 

273 up for this sequence is depicted in figure C.l below. 


274 C. 2 . 3.1 Spoofing Attempts Against Exchange and Postfix/Dovecot Configurations Using 

275 Enterprise CA Issued Certificates (CU= 1 ) 

276 The target set-up is comprised of (alternatively): Active Directory and DNS Server, BIND DNS 

277 Server, NLnet Labs DNS Services, and Secure64 DNS services with Microsoft Outlook/Exchange, 

278 Outlook/Postfix/Dovecot, and Thunderbird/Postfix/ Dovecot mail configurations. For purposes 

279 of this demonstration, two certificates were issued for each domain. One of these was valid and 

280 published as a DNSSEC signed SMIMEA RR in the target's zone. The second (spoofed) certificate 


1.Technically, this shouldn't matter. Secure64 isn't sending the mail, so the MUA isn't involved. 
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281 is not in the DNS. The fraudulent site possessed the spoofed certificates and, posing as a valid Secure 64 site, attempted to send emails to 

282 the NCCoE Laboratory target configurations. The email and DNS transactions were logged in each case, and the results are provided 

283 below. 

284 Figure C.1 Fraudulent DNS Address Spoofing Configurations 
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Expected Outcome: Using S/MIME, Outlook validated the message from the attacker (as 
DANE is not enabled in Outlook at this time). 

Observed Outcome: As expected and a log file was saved. 

2. Event 14: Thunderbird MUA, Postfix/Dovecot MTA and NLnet Labs DNS Services 

Expected Outcome: Using S/MIME and DANE, Thunderbird recognizes that the certificate 
has not been validated and does not deliver the message to the user. Thunderbird will flag 
the signature as invalid. 

Observed Outcome: As expected and a log file was saved. 

3. Event 15: Thunderbird MUA, Postfix/Dovecot MTA and Secure64 DNS Services 


Expected Outcome: Using S/MIME and DANE, Thunderbird with the Apple Key Chain Utility 
recognizes that the certificate has not been validated and does not deliver the message to 
the user. 


Observed Outcome: As expected and a log file was saved. 


300 C.2.3.2 Spoofing Attempts Against Exchange and Postfix/Dovecot Configurations Using Self- 
30, Signed Certificates (CU=3) 

302 The target set-up is configured to use Active Directory with Outlook and Exchange; and in a 

303 separate set of tests: BIND and NLnet Labs DNS Services (alternatively) were configured with a 

304 Thunderbird MUA and a Postfix/Dovecot MTA. The fraudulent site, posing as a valid Secure64 

305 site, attempted to send an email to the NCCoE Laboratory target. The email and DNS 

304 transactions were logged in each case, and the results are provided below. 


1. Event 16: Postfix MTA Using an Active Directory DNS Service 

Expected Outcome: Using only S/MIME, Outlook will fail to validate the message from the 
attacker as it was signed by an untrusted root, but not marked as a possible attack. 

Observed Outcome: As expected and a log file was saved. 

2. Event 17: Postfix MTA Using a BIND DNS Service 

Expected Outcome: Using S/MIME and DANE, Thunderbird with the Apple Key Chain Utility 
recognizes that the certificate has not been validated and does not deliver the message to 
the user. 

Observed Outcome: As expected and a log file was saved. 

3. Event 18: Postfix MTA Using an NLnet DNS Service 

Expected Outcome: Using S/MIME and DANE, Thunderbird with the Apple Key Chain Utility 
recognizes that the certificate has not been validated and does not deliver the message to 
the user. 


Observed Outcome: As expected and a log file was saved. 
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32 ,C.2.4 Sequence 4: Man-in-the-Middle Attack on Postfix-to-Postfix 

322 Connection 

323 An NCCoE system attempted to send a TLS protected email from Exchange and Postfix MTAs (in 

324 turn) to an external Postfix MTA using DNS Authority/Cache/Signer for DNS services. The NCCoE 

325 Exchange MTA used Active Directory DNS Services, and the Postfix/Dovecot MTA used BIND and 

326 NSD4/Unbound/OpenDNSSEC DNS services. A S/MIME signed email was sent to an external 

327 Postfix MTA. Four events were conducted using Well-Known CA issued certificates, four events 

32a were conducted using Enterprise CA issued certificates (TLSA/SMIMEA RR parameter of CU=2) 

329 for TLS and S/MIME on the receiver side, and three events were conducted using self-signed 

330 certificates (TLSA/SMIMEA RR parameter of CU=3) for TLS and S/MIME on the receiver side. An 

331 Outlook/Exchange/Active Directory stack acted as a man-in-the-middle and attempted to 

332 intercept the message. Figure C.2 depicts the configuration for a man-in-the-middle 

333 demonstration. Note that the sender is being misdirected to a malicious email server only. This 

334 is to simulate a lower level attack where email is sent (via route hijacking or similar low level 

335 attack) to a Man-in-the-Middle. Figure C.2 depicts the configurations used with the 

336 Thunderbird/Postfix/Dovecot/Bind option selected. 


337 C.2.4.1 Man-in-the-Middle Attack when Senders and Receivers use Well-Known CA Issued 

338 Certificates (CU=1) 

339 The sender set-up was comprised of Active Directory and DNS Server, BIND DNS Service, or 

340 NLnet Labs DNS Services with Outlook and Thunderbird MUAs using an Exchange MTA. In the 

341 fourth event, the sender is a Thunderbird MUA with a Secure64 Apple Key Chain utility utilizing 

342 NSD4/Unbound/OpenDNSSEC DNS services and a Postfix/Dovecot MTA. Enterprise CA issued 

343 certificates are used on the receiver side for TLS. Each of the four configurations attempts to 

344 initiate an email exchange with an external Secure64 site. The man-in-the-middle, an Outlook/ 

345 Exchange/Active Directory stack, attempts to spoof the intended receiver and accept the email. 

346 The email and DNS transactions were logged in each case, and the results are provided below. 
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Figure C.2 Man-in-the-Middle Event Configurations 


348 



1. Event 19: Outlook MUA, Exchange MTA, and Active Directory DNS Service as Sender 

Expected Outcome: The sending MTA fails to detect the spoofing. The mail connection to the MTA is established and mail is 
transferred. 

Observed Outcome: As expected and a log file was saved. 
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2. Event 20: Thunderbird MUA, Exchange MTA, and BIND DNS Service as Sender 

Expected Outcome: The sending MTA fails to detect the spoofing. The mail connection to 
the MTA is established and mail is transferred. 

Observed Outcome: As expected and a log file was saved. 

3. Event 21: Thunderbird MUA, Postfix MTA and NSD4/Outbound/ OpenDNSSEC DNS Services 
as Sender 

Expected Outcome: The MUA using a SMIMEA utility was able to detect the fraudulent 
email and mark the email as not validated. 

Observed Outcome: As expected and a log file was saved. 

4. Event 22: Thunderbird MUA with Secure64 Apple Key Chain Utility, Postfix/Dovecot MTA 
and DNS Authority/Cache/Signer DNS Services 

Expected Outcome: The MUA using a SMIMEA utility was able to detect the fraudulent 
email and mark the email as not validated. 

Observed Outcome: As expected and a log file was saved. 


C.2.4.2 Man-in-the-Middle Attack when Senders and Receivers use Enterprise CA Issued 
3 4 a Certificates (CU=2) 

369 The sender set-up was composed of Active Directory and DNS Server, BIND DNS Service, or 

370 NLnet Labs DNS Services with Outlook and Thunderbird MUAs using an Exchange MTA. In the 

37, fourth event, the sender is a Thunderbird MUA with a Secure64 Apple Key Chain utility utilizing 

372 NSD4/Unbound/OpenDNSSEC DNS services and a Postfix/Dovecot MTA. Enterprise CA issued 

373 certificates are used on the receiver side for TLS. Each of the four configurations attempts to 

374 initiate an email exchange with an external Secure64 site. The man-in-the-middle, an Outlook/ 

375 Exchange/Active Directory stack, attempts to spoof the intended receiver and accept the email. 

376 The email and DNS transactions were logged in each case, and the results are provided below. 


1. Event 23: Outlook MUA, Exchange MTA, and Active Directory DNS Service as Sender. 

Expected Outcome: The sending MTA fails to detect the spoofing. The mail connection to 
the MTA is established and mail transferred. 


Observed Outcome: As expected and a log file was saved. 

2. Event 24: Thunderbird MUA, Exchange MTA, and BIND DNS Service as Sender. 

Expected Outcome: The sending MTA fails to detect the spoofing. The mail connection to 
the MTA is established and mail transferred. 


Observed Outcome: As expected and a log file was saved. 

3. Event 25: Thunderbird MUA, Postifx MTA and NSD4/Outbound/OpenDNSSEC DNS Services 
as Sender 


Expected Outcome: The Postfix MTA detects the spoofing and closes the SMTP connection 
before the email is sent. 


Observed Outcome: As Expected. 

4. Event 26: Thunderbird MUA with Secure64 Apple Key Chain Utility, Postfix/Dovecot MTA 
and DNS Authority/Cache/Signer DNS Services 
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Expected Outcome: The postfix MTA detects the spoofing and closes the SMTP connection 
before the email is sent. 

Observed Outcome: As Expected. 


395 C.2.4.3 Man-in-the-Middle With Self-Signed Certificates (CU=3) 

396 The sender uses an Outlook and Thunderbird MUAs sending mail through a Postfix/Dovecot 

397 MTA and using (in turn): Active Directory and DNS Server, BIND DNS Server, and NLnet Labs DNS 

39a Services. Self-signed certificates are used on the legitimate receiver side (TLSA RR parameter 

399 CU=3) for TLS. Each of the three configurations attempts to initiate an email exchange with an 

wo external Secure64 site. The man-in-the-middle, an Outlook/Exchange/ Active Directory stack, 

401 attempts to intercept the email from the NCCoE Laboratory Configuration by acting as a Man- 

402 in-the-Middle. The email and DNS transactions were logged in each case, and the results are 

403 provided below. 


1. Event 27: Postfix MTA Using an Active Directory DNS Service 

Expected Outcome: TLSA detects spoofing. The mail connection to the MTA is established 
but breaks before the mail is transferred. 


Observed Outcome: As expected and a log file was saved. 

2. Event 28: Thunderbird MUA, Exchange MTA, and BIND DNS Service 

Expected Outcome: Exchange fails to detect the man-in-the-middle and sends the email. 
Observed Outcome: As expected and a log file was saved. 

3. Event 29: Thunderbird MUA with Secure64 Apple Key Chain Utility, Exchange MTA and 
NSD4/Outbound/OpenDNSSEC DNS Services 

Expected Outcome: Exchange fails to detect the man-in-the-middle and sends the email. 
Observed Outcome: As expected and a log file was saved. 


4 , 5 C.2.5 Sequence 5: Effects of DANE Errors 

416 In Sequence 5, A DANE-enabled Postfix MTA sent message traffic to four other postfix MTAs. 

417 See figure C.3. A single BIND instance was set up to serve the TLSA and A RRs for the four 

418 receivers. One of the receiving MTAs did not employ DANE. The second employed DANE with a 

419 valid TLSA with the certificate usage field 1 set to 3. The third employed a TLSA with a certificate 

420 usage field of 2, but with an incomplete (i.e. bad) PKI certification path (generating a PKIX 

421 validation failure). The TLSA contained a local enterprise trust anchor, but the server did not 

422 have the full certificate chain (missing intermediate certificate). The final one employed DANE 

423 with a TLSA RR using Certificate Usage of 3, but there was a mismatch between the server cert 

424 and TLSA RR (generating a DANE validation failure). 


1. RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security 
(TLS) Protocol: TLSA, Section 2.1.1. https://tools.ietf.Org/html/rfc6698#section-2.l.l 
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42 S C.2.5.1 Event 30: DNS/DANE Error Results 


The test sequence was set up as described above. The sending MTA was set with different TLS 
and DANE requirements configuration. Postfix can be configured for different "levels" of TLS 
and DANE processing and reliance. In the Postfix configuration file (main.cf) the option to turn 
on DANE processing is: 


430 smtp_tls_security_level = none | may | encrypt | dane | dane-only | fingerprint 

431 | verify | secure 

432 For this test, only none, may, dane and dane-only are relevant. These values affect how postfix 

433 establish and use TLS when sending email: 


■ none: The sender does not use TLS even when offered or available. Email is always sent in 
plaintext. 

■ may: The sender uses TLS opportunistically when available. No effort will be made to 
validate the server peer certificate, but will be used regardless. 

■ encrypt: The sender will only send mail when TLS is available, even if the server peer 
certificate is on validated. If STARTTLS is not offered, mail is deferred. 

■ dane: The sender attempts to use TLS when offered, and queries for TLSA RRs to help 
validate the server peer certificate. Mail is still sent if the validation fails, so this is 
sometimes referred to as "opportunistic DANE". 

■ dane-only: The sender only sends mail when TLS is offered, and there is a valid TLSA RR 
found. Otherwise, mail is deferred. 


Figure C.3 Failed Delivery Logs 
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Expected Outcome: Little or nothing appears in the sender's logs for messages sent to either 
the MTA not employing TLS or the employing a valid TLSA. The growth rates for logs for the MTA 
that employs a TLSA with a certificate usage field of 1, but with a PKIX failure and the one that 
employs mismatched server cert/TLSA (i.e. DANE validation failure) are measured. 


4si Observed Outcome: The delivery of the email depended on the TLS/DANE status of the 

452 receiver and the TLS/DANE configuration on the sender. The results were: 

453 

Table C.1 Transaction Results Based on Sender TLS/DANE Connection 


TLS/DANE 


Receiver TLS/DANE deployment 


Option 

No TLS 

TLS with valid DANE 

RR 

TLS with DANE PKIX 
failure 

TLS with DANE TLSA 

RR Error 

none 

Mail sent in 
plaintext 

Mail sent in plaintext 

Mail sent in plaintext 

Mail sent in plaintext 

may 

Mail sent in 
plaintext 

Mail sent over 
anonymous TLS (i.e., no 
validation of certificate) 

Mail sent over 
anonymous TLS (i.e., no 
validation of certificate) 

Mail sent over 
anonymous TLS (i.e., no 
validation of certificate) 

dane 

Mail sent in 
plaintext 

Mail sent over TLS (with 
DANE validation logged) 

Mail sent over 
anonymous TLS (i.e., no 
validation of certificate) 

Mail sent over 
anonymous TLS (i.e., no 
validation of certificate) 

dane-only 

Mail not 

sent 

Mail sent over TLS (with 
DANE validation logged) 

Mail not sent 

Mail not sent 


From the above table, when the sender was configured to never use TLS, the mail was sent in 
plaintext regardless of the TLS/DANE configuration of the receiver. When the sender was 
configured to use TLS opportunistically, it used TLS regardless of the status of the certificate, or 
TLSA. In fact, the sender did not issue a query to find TLSA RRs even if published. When the 
sender used opportunistic DANE, it used TLS when available regardless of the DANE validations 
results. If validation failed, the mail was still sent and the result was logged as an Untrusted or 
Anonymous TLS connection, depending on the presence of a TLSA RR. 


Of the four options used in the lab, dane-only was the most rigorous in what a sender will 
accept before sending mail. When the receiver did not offer the STARTTLS option, or lacked a 
TLSA RR, mail was not sent. Likewise, if a TLSA RR was present, but there was an error in 
validation (either the TLSA RR itself had an error, or PKIX failed), the mail was not sent. 
Therefore, use of this option was not recommended for general use as this resulted in the 
majority of email being deferred. It should only be used in scenarios where senders and 
receivers are coordinated and maintain a stable DANE deployment. 
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Appendix D Secure Name System (DNS) 
Deployment Checklist 


The following checklist includes actions recommended by NIST SP 800-81-2, Secure Domain 
Name System (DNS) Deployment Guide. The checklist provides secure deployment guidelines 
for each DNS component based on policies and best practices. The primary security 
specifications (with associated mechanisms) on which the checklist is based are as follows: 

■ Internet Engineering Task Force (IETF) Domain Name System Security Extensions (DNSSEC) 
specifications, covered by Request for Comments (RFC) 3833, 4033, 4034, and 4035 

■ IETF Transaction Signature (TSIG) specifications, covered by RFCs 2845 and 3007 

While not all of the checklist recommendations apply to all cases of DNS-protected email 
security, the checklist is a reliable guide for secure deployment of DNS components. 

1. Checklist item 1: When installing the upgraded version of name server software, the 
administrator should make necessary changes to configuration parameters to take 
advantage of new security features. 

2. Checklist item 2: Whether running the latest version or an earlier version, the administrator 
should be aware of the vulnerabilities, exploits, security fixes, and patches for the version 
that is in operation in the enterprise. The following actions are recommended (for BIND 
deployments): 

• Subscribe to ISC's mailing list called bind-announce or nsd-users for NSD 

• Periodically refer to the BIND vulnerabilities page at http://www.isc.org/products/ 

BIN D/bind-security, html 

• Refer to CERT/CC's Vulnerability Notes Database at http://www.kb/cert/org/vuls/ and 
the NIST NVD metabase at http://nvd.nist.gov. 

For other implementations (e.g., MS Windows Server), other announcement lists may exist. 

3. Checklist item 3: To prevent unauthorized disclosure of information about which version of 
name server software is running on a system, name servers should be configured to refuse 
queries for its version information. 

4. Checklist item 4: The authoritative name servers for an enterprise should be both network 
and geographically dispersed. Network-based dispersion consists of ensuring that all name 
servers are not behind a single router or switch, in a single subnet, or using a single leased 
line. Geographic dispersion consists of ensuring that not all name servers are in the same 
physical location, and hosting at least a single secondary server off-site. 

5. Checklist item 5: If a hidden master is used, the hidden authoritative master server should 
only accept zone transfer requests from the set of secondary zone name servers and refuse 
all other DNS queries. The IP address of the hidden master should not appear in the name 
server set in the zone database. 

6 . Checklist item 6: For split DNS implementation, there should be a minimum of two physical 
files or views. One should exclusively provide name resolution for hosts located inside the 
firewall. It also can contain RRsets for hosts outside the firewall. The other file or view 
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should provide name resolution only for hosts located outside the firewall or in the DMZ, 
and not for any hosts inside the firewall. 

7. Checklist item 7: It is recommended that the administrator create a named list of trusted 
hosts (or blacklisted hosts) for each of the different types of DNS transactions. In general, 
the role of the following categories of hosts should be considered for inclusion in the 
appropriate ACL: 

• DMZ hosts defined in any of the zones in the enterprise 

• all secondary name servers allowed to initiate zone transfers 

• internal hosts allowed to perform recursive queries 

8 . Checklist item 8: The TSIG key (secret string) should be a minimum of 112 bits in length if 
the generator utility has been proven to generate sufficiently random strings [800-57P1], 
128 bits recommended. 

9. Checklist item 9: A unique TSIG key should be generated for each set of hosts (i.e. a unique 
key between a primary name server and every secondary server for authenticating zone 
transfers). 

10. Checklist item 10: After the key string is copied to the key file in the name server, the two 
files generated by the dnssec-keygen program should either be made accessible only to the 
server administrator account (e.g., root in Unix) or, better still, deleted. The paper copy of 
these files also should be destroyed. 

11. Checklist item 11: The key file should be securely transmitted across the network to name 
servers that will be communicating with the name server that generated the key. 

12. Checklist item 12: The statement in the configuration file (usually found at /etc/named.conf 
for BIND running on Unix) that describes a TSIG key (key name (ID), signing algorithm, and 
key string) should not directly contain the key string. When the key string is found in the 
configuration file, the risk of key compromise is increased in some environments where 
there is a need to make the configuration file readable by people other than the zone 
administrator. Instead, the key string should be defined in a separate key file and referenced 
through an include directive in the key statement of the configuration file. Every TSIG key 
should have a separate key file. 

13. Checklist item 13: The key file should be owned by the account under which the name 
server software is run. The permission bits should be set so that the key file can be read or 
modified only by the account that runs the name server software. 

14. Checklist item 14: The TSIG key used to sign messages between a pair of servers should be 
specified in the server statement of both transacting servers to point to each other. This is 
necessary to ensure that both the request message and the transaction message of a 
particular transaction are signed and hence secured. 

15. Checklist item 15: Name servers that deploy DNSSEC signed zones or query signed zones 
should be configured to perform DNSSEC processing. 

16. Checklist item 16: The private keys corresponding to both the ZSK and the KSK should not 
be kept on the DNSSEC-aware primary authoritative name server when the name server 
does not support dynamic updates. If dynamic update is supported, the private key 
corresponding to the ZSK alone should be kept on the name server, with appropriate 
directory/file-level access control list-based or cryptography-based protections. 
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17. Checklist item 17: Signature generation using the KSK should be done offline, using the KSK- 
private stored offline; then the DNSKEY RRSet, along with its RRSIG RR, can be loaded into 
the primary authoritative name server. 

18. Checklist item 18: The refresh value in the zone SOA RR should be chosen with the 
frequency of updates in mind. If the zone is signed, the refresh value should be less than the 
RRSIG validity period. 

19. Checklist item 19: The retry value in a zone SOA RR should be l/10th of the refresh value. 

20. Checklist item 20: The expire value in the zone SOA RR should be 2 to 4 weeks. 

21. Checklist item 21: The minimum TTL value should be between 30 minutes and 5 days. 

22. Checklist item 22: A DNS administrator should take care when including HINFO, RP, LOC, or 
other RR types that could divulge information that would be useful to an attacker, or the 
external view of a zone if using split DNS. These RR types should be avoided if possible and 
only used if necessary to support operational policy. 

23. Checklist item 23: A DNS administrator should review the data contained in any TXT RR for 
possible information leakage before adding it to the zone file. 

24. Checklist item 24: The validity period for the RRSIGs covering a zone's DNSKEY RRSet should 
be in the range of 2 days to 1 week. This value helps reduce the vulnerability period 
resulting from a key compromise. 

25. Checklist item 25: A zone with delegated children should have a validity period of a few 
days to 1 week for RRSIGs covering the DS RR for a delegated child. This value helps reduce 
the child zone's vulnerability period resulting from a KSK compromise and scheduled key 
rollovers. 

26. Checklist item 26: If the zone is signed using NSEC3 RRs, the salt value should be changed 
every time the zone is completely resigned. The value of the salt should be random, and the 
length should be short enough to prevent a FQDN to be too long for the DNS protocol (i.e. 
under 256 octets). 

27. Checklist item 27: If the zone is signed using NSEC3 RRs, the iterations value should be 
based on available computing power available to clients and attackers. The value should be 
reviewed annually and increased if the evaluation conditions change. 

28. Checklist item 28: TTL values for DNS data should be set between 30 minutes (1800 
seconds) and 24 hours (86400 seconds). 

29. Checklist item 29: TTL values for RRsets should be set to be a fraction of the DNSSEC 
signature validity period of the RRSIG that covers the RRset. 

30. Checklist item 30: The (often longer) KSK needs to be rolled over less frequently than the 
ZSK. The recommended rollover frequency for the KSK is once every 1 to 2 years, whereas 
the ZSK should be rolled over every 1 to 3 months for operational consistency but may be 
used longer if necessary for stability or if the key is of the appropriate length. Both keys 
should have an Approved length according to NIST SP 800-57 Part 1 [800-57P1], [800-57P3], 

Zones that pre-publish the new public key should observe the following: 

31. Checklist item 31: The secure zone that pre-publishes its public key should do so at least 
one TTL period before the time of the key rollover. 
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32. Checklist item 32: After removing the old public key, the zone should generate a new 
signature (RRSIG RR), based on the remaining keys (DNSKEY RRs) in the zone file. 

33. Checklist item 33: A DNS administrator should have the emergency contact information for 
the immediate parent zone to use when an emergency KSK rollover must be performed. 

34. Checklist item 34: A parent zone must have an emergency contact method made available 
to its delegated child subzones in case of emergency KSK rollover. There also should be a 
secure means of obtaining the new KSK. 

35. Checklist item 35: Periodic re-signing should be scheduled before the expiration field of the 
RRSIG RRs found in the zone. This is to reduce the risk of a signed zone being rendered 
bogus because of expired signatures. 

36. Checklist item 36: The serial number in the SOA RR must be incremented before re-signing 
the zone file. If this operation is not done, secondary name servers may not pick up the new 
signatures because they are refreshed purely on the basis of the SOA serial number 
mismatch. The consequence is that some security-aware resolvers will be able to verify the 
signatures (and thus have a secure response) but others cannot. 

37. Checklist item 37: Recursive servers/resolvers should be placed behind an organization's 
firewall and configured to only accept queries from internal hosts (e.g., Stub Resolver host). 

38. Checklist Item 38: Whenever Aggregate Caches are deployed, the forwarders must be 
configured to be Validating Resolvers. 


39. Checklist item 39: Each recursive server must have a root hints file containing the IP 
address of one or more DNS root servers. The information in the root hints file should be 
periodically checked for correctness. 


40. Checklist item 40: The root hints file should be owned by the account under which the 
name server software is run. The permission bits should be set so that the root hints file can 
be read or modified only by the account that runs the name server software. 


41. Checklist item 41: Administrators should configure two or more recursive resolvers for each 
stub resolver on the network. 


42. Checklist item 42: Enterprise firewalls should consider restricting outbound DNS traffic 
from stub resolvers to only the enterprise's designated recursive resolvers. 

43. Checklist item 43: Each recursive server must have a root hints file containing the IP 
address of one or more DNS root servers. The information in the root hints file should be 
periodically checked for correctness. 

44. Checklist item 44: The root hints file should be owned by the account under which the 
name server software is run. The permission bits should be set so that the root hints file can 
be read or modified only by the account that runs the name server software. 

45. Checklist item 45: Administrators should configure two or more recursive resolvers for each 
stub resolver on the network. 


46. Checklist item 46: Enterprise firewalls should consider restricting outbound DNS traffic 
from stub resolvers to only the enterprise's designated recursive resolvers. 

47. Checklist item 47: Non-validating stub resolvers (both DNSSEC-aware and non-DNSSEC- 
aware) must have a trusted link with a validating recursive resolver. 
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48. Checklist item 48: Validators should routinely log any validation failures to aid in diagnosing 
network errors. 

49. Checklist item 49: Mobile or nomadic systems should either perform their own validation 
or have a trusted channel back to a trusted validator. 

50. Checklist item 50: Mobile or nomadic systems that perform its own validation should have 
the same DNSSEC policy and trust anchors as validators on the enterprise network. 

51. Checklist item 51: Validator administrator must configure one or more trust anchors for 
each validator in the enterprise. 

52. Checklist item 52: The validator administrator regularly checks each trust anchor to ensure 
that it is still in use, and updates the trust anchor as necessary. 
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.Appendix E Overview of Products Contributed 
by Collaborators 


Components provided by collaborators included Mail User Agents (MUAs), Mail Transfer Agents 
(MTAs), and DNS Services. Most of the products included were DNS service components, but 
these DNS service components were initially provided with MUAs and MTAs in all cases. Where 
the MUA and MTA components employed are not part of the collaborator's standard offering, 
open source MUA and MTA components were included in the initial collaborator installation. 
Component overviews follow: 


,E.1 Open Source MUA and MTA Components 

,o E. 1.1 Thunderbird Mail User Agent 

Mozilla Thunderbird is a free, open source, cross-platform email, news, and chat client 
12 developed by the Mozilla Foundation. Thunderbird is an email, newsgroup, news feed, and chat 

is (XMPP, IRC, Twitter) client. The Mozilla Lightning extension, which is installed by default, adds 

14 PIM functionality. Thunderbird can manage multiple email, newsgroup, and news feed 

is accounts and supports multiple identities within accounts. Features such as quick search, saved 

i 6 search folders (virtual folders), advanced message filtering, message grouping, and labels help 

I? manage and find messages. On Linux-based systems, system mail (movemail) accounts are 

is supported. Thunderbird incorporates a Bayesian spam filter, a whitelist based on the included 

19 address book, and can also understand classifications by server-based filters such as 

20 SpamAssassin. 

21 Thunderbird has native support for RFC 3851 S/MIME, but RFC 5757 (S/MIME version 3.2) is not 

22 supported. Support for other security systems can be added by installing extensions (e.g, the 

23 Enigmail extension adds support for PGP). S/MIME and PGP cannot both be used in the same 

24 message. SSL/TLS is also supported, but it is used only to temporarily encrypt data being send 

25 and received between an email client and server. SSL/TLS can work in combination with S/ 

26 MIME or OpenPGP. 

27 Thunderbird supports POP and IMAP. It also supports LDAP address completion. Thunderbird 

2 a supports the S/MIME standard, extensions such as Enigmail add support for the OpenPGP 

29 standard. A list of supported IMAP extensions can be found at wiki.mozilla.org. Since version 

30 38, Thunderbird has integrated support for automatic linking of large files instead of attaching 

31 them directly to the mail message. 

32 Thunderbird runs on a variety of platforms. Releases available on the primary distribution site 

33 support Linux, Windows, and OS X operating systems. Unofficial ports are available for FreeBSD, 

34 OpenBSD, OpenSolaris, OS/2, and eComStation. 

35 E. 1.2 Dovecot 

36 Dovecot is used in the DNS-Based Email Security project to permit MUA access to the Postfix 

37 MTA. Dovecot is an open source IMAP 1 and POP3 email server for Linux/UNIX-like systems, 
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written with security primarily in mind. Dovecot is used in both small and large installations. It 
is compact and requires no special administration and it uses very little memory. Dovecot 
supports the standard mbox and Maildir formats. The mailboxes are transparently indexed and 
provide full compatibility with existing mailbox handling tools. Dovecot vl.l passes all IMAP 
server standard compliance tests. Dovecot allows mailboxes and their indexes to be modified 
by multiple computers at the same time, providing compatibility with clustered file systems. 
Caching problems can be worked around with director proxies. Postfix 2.3+ and Exim 4.64+ 
users can do SMTP authentication directly against Dovecot's authentication backend without 
having to configure it separately, and Dovecot supports easy migration from many existing 
IMAP and POP3 servers, allowing the change to be transparent to existing users. 

Dovecot currently offers IMAP4revl, POP3, IPv6, SSL and TLS support. It supports multiple 
commonly used IMAP extensions, including SORT, THREAD and IDLE. Shared mailboxes are 
supported in vl.2+. Maildir++ quota is supported, but hard file system quota can introduce 
problems. Dovecot is commonly used with Linux, Solaris, FreeBSD, OpenBSD, NetBSD and Mac 

OS X. See the Dovecot Wiki page (http://wiki2.dovecot.org/OSCompatibility) about OS 
compatibility for more. 


E.1.3 Postfix 

Postfix is a free and open-source mail transfer agent (MTA) that routes and delivers electronic 
mail. Postfix is released under the IBM Public License 1.0 which is a free software license. As an 
SMTP client, Postfix implements a high-performance parallelized mail-delivery engine. Postfix is 
often combined with mailing-list software (such as Mailman). 

Postfix consists of a combination of server programs that run in the background, and client 
programs that are invoked by user programs or by system administrators. The Postfix core 
consists of several dozen server programs that run in the background, each handling one 
specific aspect of email delivery. Examples are the SMTP server, the scheduler, the address 
rewriter, and the local delivery server. For damage-control purposes, most server programs run 
with fixed reduced privileges, and terminate voluntarily after processing a limited number of 
requests. To conserve system resources, most server programs terminate when they become 
idle. 

Client programs run outside the Postfix core. They interact with Postfix server programs 
through mail delivery instructions in the user's ""/.forward file, and through small "gate" 
programs to submit mail or to request queue status information. 

As an SMTP server, Postfix implements a first layer of defense against spambots and malware. 
Administrators can combine Postfix with other software that provides spam/virus filtering (e.g., 
Amavisd-new), message-store access (e.g., Dovecot), or complex SMTP-level access-policies 
(e.g., postfwd, policyd-weight or greylisting). 


1. The Internet Message Access Protocol (IMAP) is a mail protocol used for accessing email on a 
remote web serverfrom a local client. IMAP and POP3 are the two most commonly used Internet 
mail protocols for retrieving emails. Both protocols are supported by all modern email clients 
and web servers. 
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Features include: 

■ standards-compliant support for SMTPUTF8, SMTP, LMTP, STARTTLS encryption including 
DANE protocol support and "perfect" forward secrecy, SASL authentication, MIME 
encapsulation and transformation, DSN delivery status notifications, IPv4, and IPv6 

■ configurable SMTP-level access policy that automatically adapts to overload 

■ virtual domains with distinct address-namespaces 

■ UNIX-system interfaces for command-line submission, for delivery to command, and for 
direct delivery to message stores in mbox and maildir format 

■ light-weight content inspection based on regular expressions 

■ database lookup mechanisms including Berkeley DB, CDB, OpenLDAP LMDB, Memcached, 
LDAP and multiple SQL database implementations 

■ a scheduler that implements parallel deliveries, with configurable concurrency and back-off 
strategies 

■ a scalable zombie blocker that reduces SMTP server load due to botnet spam 

Postfix extensions use the SMTP or Milter (Sendmail mail filter) protocols which both give full 
control over the message envelope and content, or a simple text-based protocol that enables 
complex SMTP-level access control policies. Extensions include: 

■ deep content inspection before or after a message is accepted into the mail queue 

■ mail authentication with DMARC, DKIM, SPF, or other protocols 

■ SMTP-level access policies such as greylisting or rate control 

Postfix runs on BSD, GNU/Linux, OS X, Solaris and most other Unix-like operating system, 
generally ships with a C compiler, and delivers a standard POSIX development environment. It is 
the default MTA for the OS X, NetBSD and Ubuntu operating systems. 


E.2 Microsoft Windows-Based Components 

Microsoft's contribution includes a complete MUA, MTA, and DNS service stack, though each of 
the components can be integrated into systems provided by other contributors. 


E.2.1 Outlook 

Microsoft Outlook is a personal information manager from Microsoft, available as a part of the 
Microsoft Office suite. Although often used mainly as an email application, it also includes a 
calendar, task manager, contact manager, note taking, journal, and web browsing. It can be 
used as a stand-alone application, or can work with Microsoft Exchange Server and Microsoft 
SharePoint Server for multiple users in an organization, such as shared mailboxes and 
calendars, Exchange public folders, SharePoint lists, and meeting schedules. Microsoft has also 
released mobile applications for most mobile platforms, including iOS and Android. Developers 
can also create their own custom software that works with Outlook and Office components 
using Microsoft Visual Studio. In addition, mobile devices can synchronize almost all Outlook 
data to Outlook Mobile. Microsoft Outlook mail system uses the proprietary Messaging 
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Application Programming Interface (MAPI) to access Microsoft Exchange electronic mail 
servers. 

Outlook supports S/MIME (Secure/Multipurpose Internet Mail Extensions) is a standard for 
public key encryption and signing of MIME data. S/MIME is on an IETF standards track and 
defined in a number of documents, most importantly RFCs 3369, 3370, 3850 and 3851. 


„„E.2.2 Exchange 

ii 7 Microsoft Exchange Server is a calendaring and mail server developed by Microsoft that runs 

iie exclusively on the Microsoft Windows Server product line. Exchange Server was initially 

n 9 Microsoft's internal mail server but is now published outside Microsoft. It uses the Active 

no Directory directory service. It is bundled with the Outlook email client. 

121 Exchange Server supports POP3, IMAP, SMTP and EAS. It also supports IPv 6 , SMTP overTLS, PoP 

122 over TLS, NNTP, and SSL. Exchange Server is licensed both in the forms of on-premises software 

123 and software as a service. In the on-premises form, customer purchase client access licenses 

124 (CALs). In the software as a service form, Microsoft receives a monthly service fee instead (see 

125 https://en.wikipedia.org/wiki/Office_365). 


,2 4 E.2.3 Server DNS Services 

127 Windows Server 2016 is a server operating system developed by Microsoft as part of the 

12 a Windows NT family of operating systems, developed concurrently with Windows 10. Microsoft 

129 Server features server virtualization, networking, server management and automation, a web 

130 and application platform, access and information protection, and virtual desktop infrastructure. 

1 3 1 Key operating system elements for the DNS-Based Email Security project are Active Directory 

132 and DNS Server. 


133 E.2.3.1 Active Directory 

134 Active Directory (AD) is a directory service that Microsoft developed for Windows domain 

135 networks. It is included in most Windows Server operating systems as a set of processes and 

136 services. Initially, Active Directory was only in charge of centralized domain management. 

1 37 Active Directory is an umbrella title for a broad range of directory-based identity-related 

138 services. A server running Active Directory Domain Services (AD DS) is called a domain 

139 controller. It authenticates and authorizes all users and computers in a Windows domain type 

1 4 0 network-assigning and enforcing security policies for all computers and installing or updating 

1 4 1 software. For example, when a user logs into a computer that is part of a Windows domain, 

142 Active Directory checks the submitted password and determines whether the user is a system 

143 administrator or normal user. 


Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft's 
version of Kerberos, and DNS. Active Directory Domain Services (AD DS) is the cornerstone of 
every Windows domain network. It stores information about members of the domain, including 
devices and users, verifies their credentials and defines their access rights. The server (or the 
cluster of servers) running this service is called a domain controller. A domain controller is 
contacted when a user logs into a device, accesses another device across the network, or runs a 
line-of-business Metro-style application side loaded into a device. Other Active Directory 
services (excluding LDS, as well as most of Microsoft server technologies rely on or use Domain 
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152 

Services; examples include Group Policy, Encrypting File System, BitLocker, Domain Name 

153 

Services, Remote Desktop Services, Exchange Server and SharePoint Server. 

154 

Active Directory Certificate Services (AD CS) establishes an on-premises public key 

155 

infrastructure. It can create, validate and revoke public key certificates for internal uses of an 

156 

organization. These certificates can be used to encrypt files (when used with Encrypting File 

157 

System), emails (per S/MIME standard), network traffic (when used by virtual private networks, 

158 

Transport Layer Security protocol or IPSec protocol). 

.59 E.2.3.2 

DNS Server 

160 

Microsoft Windows server operating systems can run the DNS Server service, a monolithic DNS 

161 

server that provides many types of DNS service, including caching, Dynamic DNS update, zone 

162 

transfer, and DNS notification. DNS notification implements a push mechanism for notifying a 

163 

select set of secondary servers for a zone when it is updated. DNS Server has improved 

164 

interoperability with BIND and other implementations in terms of zone file format, zone 

165 

transfer, and other DNS protocol details. 

166 

Microsoft's DNS server supports different database back ends. Microsoft's DNS server supports 

167 

two such back ends. DNS data can be stored either in master files (also known as zone files) or 

168 

in the Active Directory database itself. In the latter case, since Active Directory (rather than the 

169 

DNS server) handles the actual replication of the database across multiple machines, the 

170 

database can be modified on any server (multiple-master replication), and the addition or 

171 

removal of a zone will be immediately propagated to all other DNS servers within the 

172 

appropriate Active Directory "replication scope". (Contrast this with BIND, where when such 

173 

changes are made, the list of zones, in the /etc/named.conf file, has to be explicitly updated on 

174 

each individual server.) 

175 

Microsoft's DNS server can be administered using either a graphical user interface, the DNS 

176 

Management Console, or a command line interface, the dnscmd utility. New to Windows 

177 

Server 2012 is a fully featured PowerShell provider for DNS server management. 

,7. E.3 

NLnet Labs Name Server Daemon-Based 

179 

Components 

.so E.3.1 

NSD4 Authoritative Name Server 

181 

Name Server Daemon (NSD) is an open-source DNS server. It was developed from scratch by 

182 

NLnet Labs of Amsterdam in cooperation with the RIPE NCC, as an authoritative name server 

183 

(i.e., not implementing the recursive caching function by design). The intention of this 

184 

development is to add variance to the "gene pool" of DNS implementations originally intended 

185 

for root servers, top-level domains (TLDs) and second-level domains (SLDs), thus increasing the 

186 

resilience of DNS against software flaws or exploits. 

187 

NSD uses BIND-style zone-files (zone-files used under BIND can usually be used unmodified in 

188 

NSD, once entered into the NSD configuration). 

189 

The collection of programs/processes that make-up NSD are designed so that the NSD daemon 

190 

itself runs as a non-privileged user and can be easily configured to run in a Chroot jail, such that 
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security flaws in the NSD daemon are not so likely to result in system-wide compromise as 
without such measures. 


The latest current stable release is NSD 4 . 1 . 13 . Download the latest version here: https:// 
www.nlnetlabs.nl/downloads/nsd/nsd-4.1.10.tar.gz. 

NSD is thoroughly tested, there is a regression tests report available. 

For NSD 4 , the memory estimation tool can be compiled in the source tarball with make nsd- 
mem and running it on a config file with the zone files in question. 

NLnet Labs has a long-term commitment for supporting NSD. There will be an advanced notice 
when the organization's commitment ends. The latest NSD release will supported for at least 
two years after an end-of-life notification has been sent to the community. 


Manual pages are installed, they can also be viewed: 

1. nsd( 8 ) man page: https://www.nlnetlabs.nI/projects/nsd/nsd. 8 .html 

2. nsd-control( 8 ) man page: https://www.nlnetlabs.nI/projects/nsd/nsd-control. 8 .html 

3. nsd-checkconf( 8 ) man page: https://www.nlnetlabs.nI/projects/nsd/nsd-checkconf. 8 .html 

4. nsd-checkzone( 8 ) man page: https://www.nlnetlabs.nI/projects/nsd/nsd-checkzone. 8 .html 

5. nsd.conf(5) man page: https://www.nlnetlabs.nI/projects/nsd/nsd.conf.5.html 

NSD users can subscribe to nsd-users and browse the archives of nsd-users here http:// 
open.nlnetlabs.nl/mailman/listinfo/nsd-users/. 

The repository of NSD is available at /svn/nsd/, the NSD 4.x.x development tree is located in 
trunk/. 


2 „E.3.2 OpenDNSSEC Domain Name Security Manager 

212 OpenDNSSEC software manages the security of domain names on the Internet. The 

2 1 3 OpenDNSSEC project is a cooperative effort intended to drive adoption of Domain Name 

214 System Security Extensions (DNSSEC) in order to further enhance Internet security. 

2 1 5 OpenDNSSEC was created as an open-source turn-key solution for DNSSEC. It secures DNS zone 

2 1 6 data just before it is published in an authoritative name server. OpenDNSSEC takes in unsigned 

2 1 7 zones, adds digital signatures and other records for DNSSEC and passes it on to the 

218 authoritative name servers for that zone. OpenDNSSEC will furthermore take care of the key 

219 management and roll-over procedure to replace keys. It acts as a bump in the wire, where it 

220 will fit in an existing DNS tool chain without modification in that tool chain. Incrementally 

221 incorporating changes and re-using already signed zones to perform a constant up-to-date 

222 zone. 


All keys are stored in a hardware security module and accessed via PKCS #11, a standard 
software interface for communicating with devices which hold cryptographic information and 
perform cryptographic functions. OpenDNSSEC uses SoftHSM, OpenSSL, the Botan 
cryptographic library, and SQLite or MySQL as database back-end. It is used on the .se, .dk, .nl 
.ca, .za, .uk, and other top-level domains. OpenDNSSEC can be downloaded from: 

■ https://dist.opendnssec.Org/source/opendnssec-2.0.l.tar.gz 

■ https://dist.opendnssec.Org/source/opendnssec-2.0.l.tar.gz.sig 
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■ Checksum SHA256: 

bf874bbb346699a5b539699f90a54e0cl5fff0574df7a3cll8abb30938b7b346 

In August of 2014, NLnet Labs took responsibility for continuing the OpenDNSSEC activities of 
both the OpenDNSSEC software project and the Swedish OpenDNSSEC AB. 


E.3.3 Unbound DNS Resolver 
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Unbound is a validating, recursive, and caching DNS resolver. The C implementation of 
Unbound is developed and maintained by NLnet Labs. It is based on ideas and algorithms taken 
from a Java prototype developed by Verisign labs, Nominet, Kirei and ep.net. Unbound is 
designed as a set of modular components, so that also DNSSEC (secure DNS) validation and 
stub-resolvers (that do not run as a server, but are linked into an application) are easily possible. 

The source code is under a BSD License. 

Release 1.5.9 of Unbound was released June 9, 2016. The repository for unbound is available 
https://unbound.nlnetlabs.nl/svn/. The development tree is located in trunk/. 

The latest source code tarball is available for download. 

Unbound problems can be reported through the NLnet Labs bugzilla web interface. In the case 
NLnet Labs will stop supporting the product, and they will announce such two years in advance. 
Unbound is subject to NLnet Labs Security Patch Policy. Commercial support for Unbound is 
available from several organizations. 


E.4 ISC BIND Component 
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Internet Systems Consortium, Inc., also known as ISC, is a non-profit corporation that supports 
the infrastructure of the Internet by developing and maintaining core production-quality 
software, protocols, and operations. ISC has developed several key Internet technologies that 
enable the global Internet, including BIND. 

BIND is open source software that implements the Domain Name System (DNS) protocols for 
the Internet. It is a reference implementation of those protocols, but it is also production-grade 
software, suitable for use in high-volume and high-reliability applications. The acronym BIND 
stands for Berkeley Internet Name Domain, because the software originated in the early 1980s 
at the University of California at Berkeley. 

BIND is widely used DNS software that provides a stable platform on top of which organizations 
can build distributed computing systems that are fully compliant with published DNS standards. 

BIND is transparent open source. If an organization needs some functionality that is not in 
BIND, it is possible to modify it, and contribute the new feature back to the community by 
sending ISC its source. It is possible to download a tar ball from the ISC web site (https:// 

www.isc.org/downloads/), ftp.isc.org (http://ftp.isc.org/isc/bind9/cur/), or a binary from an 
organization's operating system repository. 


The BIND software distribution has three parts: 


DNS-Based Email Security Practice Guide 


100 




Chapter E. 


E.4.1 Domain Name Resolver 
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The BIND resolver is a program that resolves questions about names by sending those 
questions to appropriate servers and responding appropriately to the servers' replies. In the 
most common application, a web browser uses a local stub resolver library on the same 
computer to look up names in the DNS. That stub resolver is part of the operating system. 
(Many operating system distributions use the BIND resolver library.) The stub resolver usually 
will forward queries to a caching resolver, a server or group of servers on the network 
dedicated to DNS services. Those resolvers will send queries to one or multiple authoritative 
servers in order to find the IP address for that DNS name. 

DNS authoritative operations include the following features: 

1. NXDOMAIN Redirect: When a user searches for a non-existent domain, (NXDOMAIN 
response) the user can be redirected to another web page. This is done using the BIND DLZ 
feature. 

2. Flexible Cache Controls: From time to time users can get incorrect or outdated records in 
the resolver cache. BIND gives users the ability to remove them selectively or wholesale. 

3. Split DNS: BIND provides the ability to configure different views in a single BIND server. This 
allows users to give internal (on-network) and external (from the Internet) users different 
views of DNS data, keeping some DNS information private. 

4. Cache Hit Rate Optimization: BIND is designed to be persistent and resilient in resolving 
queries even when there is a delay in responding, in order to populate the cache for later 
requests. DNS Pre-fetch is a technique for continuously refreshing the cached records for 
popular domains, reducing the time the user has to wait for a response. 

5. Resolver Rate-limiting: Beginning with BIND 9.10.3, two new configuration parameters 
were added, fetches-per-zone and fetches-per-server. These features enable rate-limiting 
queries to authoritative systems that appear to be under attack. These features have been 
successful in mitigating the impact of a DDOS attack on resolvers in the path of the attack. 

6. DNSSEC Validation: DNSSEC validation protects clients from impostor sites. In BIND, this is 
enabled with a single command. BIND supports RFC 5011 maintenance of root key trust 
anchors. BIND also has a Negative Trust Anchor feature (introduced in the 9.9 subscription 
branch), which temporarily disables DNSSEC validation when there is a problem with the 
authoritative server's DNSSEC support. 

7. Geo IP: GeolP, or Geographic IP, allows a BIND DNS server to provide different responses 
based on the network information about the recursive DNS resolver that a user is using. 
There is an active Internet Draft describing another mechanism for providing location 
information, called EDNS-Client-Subnet-ldentifier. This requires the resolver to cache 
multiple different addresses for a given DNS record, depending on the address of the 
requester. This feature has not been added to the BIND9 resolver, although the 
corresponding feature has been developed for the BIND9 authoritative server. 

8. Response Policy Zone: A Response Policy Zone or RPZ is a specially-constructed zone that 
specifies a policy rule set. The primary application is for blocking access to zones that are 
believed to be published for abusive or illegal purposes. There are companies who 
specialize in identifying abuse sites on the Internet, who market these lists in the form of 
RPZ feeds. For more information on RPZ, including a list of DNS reputation feed providers, 
see https://dnsrpz.info. 
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311 The authoritative DNS server answers requests from resolvers, using information about the 

an domain names it is authoritative for. Enterprises can provide DNS services on the Internet by 

313 installing this software on a server and giving it information about the enterprise's domain 

314 names. 


1. Response Rate Limiting: An enhancement to the DNS protocol to reduce the problem of 
"amplification attacks" by limiting DNS responses. Response rate limiting is on by default. 

2. Dynamically-Loadable Zones: enable BIND9 to retrieve zone data directly from an external 
database. This is not recommended for high-query rate authoritative environments. 

3. Reload Time Reduction: BIND server zone files can be updated via nsupdate, and 'dynamic' 
zone files can be added via RNDC, both without restarting BIND. For those times when it is 
necessary to restart, the MAP zone file format can speed up re-loading a large zone file into 
BIND, such as on restart. 


4. Hardware Security Modules: BIND supports the use of Hardware Security Modules through 
either a native PKCS#11 interface, or the OpenSSL PKCS#11 provider. HSMs are used to 
store key material outside of BIND for security reasons. 

5. DNSSEC With In-line Signing: BIND fully supports DNSSEC With In-line Signing and has an 
easy-to use implementation. Once an enterprise has initially signed its zones, BIND can 
automatically re-sign the records as they are updated with in-line signing, maintaining the 
DNSSEC validity of the records. BIND supports both NSEC and NSEC3 and inline signing 
works with NSEC3. 


6 . Catalog Zones: Catalog Zones were introduced in BIND 9.11.0 to facilitate the provisioning 
of zone information across a nameserver constellation. Catalog Zones are particularly useful 
when there are a large number of secondary servers. A special zone of a new type, a catalog 
zone, is set up on the master. Once a catalog zone is configured, when an operator wishes to 
add a new zone to the nameserver constellation s/he can provision the zone in one place 
only, on the master server and add an entry describing the zone to the catalog zone. As the 
secondary servers receive the updated copy of the catalog zone data they will note the new 
entry and automatically create a zone for it. Deletion of a zone listed in a catalog zone is 
done by deleting the entry in the catalog zone on the master. 


7. Scalable Master/Slave Hierarchy: A DNS authoritative system is composed of a zone 

primary or master with one or more slave servers. Zones files are established and updated 
on a master BIND server. Slaves maintain copies of the zone files and answer queries. This 
configuration allows scaling the answer capacity by adding more slaves, while zone 
information is maintained in only one place. The master signals that updated information is 
available with a notify message to the slaves, and the slaves then initiate an update from 
the master. BIND fully supports both the AXFR (complete transfer) and IXFR (incremental 
transfer) methods, using the standard TSIG security mechanism between servers. There are 
a number of configuration options for controlling the zone updating process. 


34,E.4.3 Tools 

350 ISC includes a number of diagnostic and operational tools. Some of them, such as the popular 

35 1 DIG tool, are not specific to BIND and can be used with any DNS server. 
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3S2 E.5 Secure64 Component 

353 The Secure64 contributions included an automated online Secure64 DNS Signer delivered on 

354 dedicated hardware and DNSSEC-capable VM images of DNS Cache, DNS Authority, and DNS 

355 Manager. DNS Manager provided centralized management of Secure64 DNS Cache software 

356 and configurations and provided network-wide monitoring of key performance indicators. DNS 

357 Manager allowed creation of groups of servers and assignment of configurations to a group, a 

358 single server, or all servers. DNS Authority is an authoritative signer and server as a single 

359 platform. This stack was able to demonstrate Outlook, Thunderbird, or Apple Mail as MUAs and 

360 uses Postfix as an MTA and Dovecot to provide IMAP for clients. Descriptions of the DNS service 

361 components follow: 


363 E.5.1 DNS Signer 

363 Secure64 DNS Signer is DNSSEC key management and zone signing software that is designed to 

364 facilitate and provide security for DNSSEC implementation. Secure64 DNS Signer fully 

365 automates DNSSEC key generation, key rollover, zone signing and re-signing processes, It is 

366 designed to scale to large, dynamic environments by maintaining DNSSEC signing keys securely 

367 online while providing incremental zone signing and high signing performance. Signer 

368 integrates into existing infrastructures configurations. It is fully compatible with Secure64 DNS 

369 Authority, BIND, NSD, and Microsoft DNS masters and slaves. Signer supports all of the RFCs 

370 and best practices required to deploy DNSSEC. 


37 , E.5.2 DNS Authority 


Secure64 DNS Authority is a name server software product. It provides built-in DoS protection 
that identifies and blocks TCP or UDP attack traffic. It is designed to respond to legitimate 
queries, even while under attack. DNS Authority provides real-time alerts and attack 
characteristics through syslog and SNMP traps in order to enable remedial action. Authority is 
also designed to be anycasted in any data center, even for enterprises that don't operate the 
routing infrastructure. The administrator can insert and withdraw servers without requiring 
router changes or deploying dedicated router hardware. Authority directly reads existing BIND 
configuration files and is interoperable with name servers running BIND, NSD, or Microsoft 
Windows DNS software. Some specific features include the following: 

1. IPv6 support: Authority supports IPv 6 in either dual stack or IPv 6 -only mode. 

2. PipeProtector: Authority's PipeProtectorTM feature protects networks by automatically 
identifying the sources of amplified flood attacks and communicating with the upstream 
router to blackhole the attack traffic. 


3. Built-in BGP: Built-in Border Gateway Protocol (BGP) permits Authority to be set up in an 
anycast configuration, which provides greater resiliency against denial-of-service attacks 
and improved performance. After BGP is initially configured, the administrator can insert 
and withdraw the server from the anycast cluster without making router changes. 

4. Secured runtime environment: Authority is designed to run on a SourceT operating system 
and to utilizes server hardware security capabilities to eliminate all paths for injection or 
execution of malicious code at runtime. 
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5. System Authentication: Digital signatures of the firmware, operating system and 
application code are all validated during the boot process. This protects against the 
operating system and the application code images on disk from being compromised by a 
rootkit. 


6 . Secured zone data: Authority provides end-to-end integrity protection of zone data by 
supporting DNSSEC, TSIG and ACLs for queries, notifies and zone transfers. 

7. Synthesized PTR records: Reverse DNS records for IPv 6 addresses or other large address 
blocks can be generated on the fly where necessary to preserve compatibility with other 
systems that rely upon the existence of these reverse records. 

8 . Standards support: Authority supports ENUM standards, including RFC 3163 (SIP initiation 
protocol), RFC 6116 (storage of data for E.164 numbers in the DNS) and 3GPP TS 29.303 
(DNS procedures for the Evolved Packet System). 

9. Split horizon DNS: Views permit configuration of an authoritative server to provide 
different functionality and responses based on characteristics of the requesting client. 


^E.5.3 DNS Cache 


Secure64 DNS Cache is scalable, secure, caching DNS software designed to provide built-in 
protection against high volume denial-of-service attacks and immunity to BIND-specific security 
vulnerabilities. DNS Guard is a family of security services that protect users and the network 
from malicious activity, while the Web Error Redirection Module allows service providers to 
improve the end user's experience while generating incremental revenues that flow right to the 
bottom line. Some specific features include the following: 


1. IPv6 Support: DNS Cache supports both dual stack and deployment of a pure IPv 6 network 
while providing compatibility with IPv4 networks. 

2. Built-In DDoS Protection: Built-in DDoS detection and mitigation allows DNS Cache to 
continue to respond to legitimate queries while fending off high volume denial-of-service- 
attacks. This combats a common issue with DNS solutions that crash or become unavailable 
at lower levels of attack traffic. In addition to mitigating high volume attacks, DNS Cache 
automatically detects cases of individual clients exceeding a user-defined query threshold 
and temporarily blacklists them while logging information about the offending client. This 
helps prevent inadvertent participation in a denial-of-service attack. 


422 3. SNMP: DNS Cache provides several MIBs, that allow monitoring of the chassis, network, 

423 operating system and application in real time and support a variety of network monitoring 

424 systems. In addition, DNS Cache directly provides alerts of critical operational conditions 

425 through SNMP traps without requiring special configuration within the network monitoring 

426 system. 


4. Centralized management: DNS Cache servers can be managed individually, or can be 
centrally managed and monitored through Secure64 DNS Manager. 


5. Scalable performance: At a 90% cache hit rate, DNS Cache delivers over 125,000 queries 
per second, which can easily be increased to 280,000 queries per second through the 
optional software-based Capacity Expansion Module. 


6 . DNSSEC validation overrides: DNS Cache can configured to validate DNSSEC signed 
answers. Because DNSSEC configuration errors are not uncommon, operators can readily 


DNS-Based Email Security Practice Guide 


104 




Chapter E. 


identify domains failing validation and specify which of these should be allowed to resolve 
normally. 

7. Merge Zones: DNS Cache's merge zones feature allows a number of dynamic authoritative 
zones to be split up among different authoritative servers, each of which is queried for a 
response to a query for that zone until an answer is received. 

8 . Web Error Redirection Module: The optional Web Error Redirection Module allows service 
providers to redirect NXDOMAIN responses from authoritative servers to a provider- 
branded search portal that helps guide users to their intended designation. 

9. Rules engine: DNS Cache's rules engine provides fine-grained control over which responses 
are redirected, and includes built-in support for opt-out. 


444 E.5.4 DNS Manager 

445 DNS Manager provides centralized management of Secure64 DNS Cache software and 

446 configurations and provides network-wide monitoring of key performance indicators. This GUI 

447 based application can configure, manage, and monitor a set of Secure64 DNS Cache servers 

44 a from one central point. In an environment consisting of many DNS servers, there are likely to be 

449 differences in configurations. Some servers may be anycasted, while others are load balanced, 

450 for example. Or servers located in different geographies may have different values for local DNS 

451 data. DNS Manager allows creation of groups of servers and assigns configurations to a group, a 

452 single server, or all servers. Groups may be arranged hierarchically. Common configuration 

453 parameters may be assigned to all servers in the network, whereas settings specific to subsets 

454 of servers may be assigned at the group level, and IP addresses and other server-specific 

455 information are assigned to each specific server. All actions to modify configuration files or 

456 software versions are revision controlled and logged. Authorized users can rollback to previous 

457 software versions or configurations if necessary. DNS Manager is able to monitor key 

458 performance indicators across the DNS network, including queries per second, CPU, disk and 

459 memory utilization. 


460 E.5.5 Secure64 Apple Key Chain Utility 

461 The Apple Key Chain Utility is a Secure64 utility for Public Key Retrieval into the Apple Key 

462 Chain. This utility is delivered on a MacBook loaded with Apple Mail and is a program for the 

463 MacBook that will fetch SMIMEA records and put them in the keystore so that we can 

464 demonstrate end-to-end security. 
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.Appendix F Installation and Configuration Log 
for NSD4, Unbound, and 
OpenDNSSEC 


4 The following log captures the installation and configuration process for NSD4, Unbound, and 

5 OpenDNSSEC for the NCCoE's DNS-Based Email Security project. Please note that the IP 

6 addresses, domain names, and mail addresses are for the NCCoE laboratory and must not be 

7 used in actual implementations. 

8#### 

9 # Unbound installation log for 10.33.XX.XX 
10### 

11 

12 

13 # Unbound does not depend on a resolver for its installation. However, I 
14 # configure one here so I can use yum from installation of the dependencies, 
is [rdolmans@unbound ~]$ sudo cp /etc/resolv.conf /etc/resolv.conf.orig 

16 [rdolmans@unbound ~]$ echo "nameserver 10.97.XX.X" | sudo tee -a /etc/resolv.conf 

17 

18 

19 # Install build tools 

20 [rdolmans@unbound ~]$ sudo yum group install "Development Tools" 

21 
22 

23 # Install unbound dependencies: openssl, expat 

24 [rdolmans@unbound ~]$ sudo yum install openssl-devel expat-devel 

25 

26 

27 # Download Unbound and verify 

28 [rdolmans@unbound ~]$ curl https://unbound.net/downloads/unbound-1.5.8.tar.gz -o unbound- 
291.5.8. tar.gz 

30 [rdolmans@unbound ~]$ cat unbound-1.5.8.tar.gz | openssl sha256 

31 (stdin)= 33567a20f73e288f8daa4ec021fbb30fel824b346b34f12677ad77899ecd09be 

32 

33 

34 # We do not need a nameserver anymore, move back old resolv.conf 

35 [rdolmans@unbound ~]$ sudo mv /etc/resolv.conf.orig /etc/resolv.conf 

36 

37 

38# extract, ./configure, compile and install Unbound 

39 [rdolmans@unbound ~]$ tar xvzf unbound-1.5.8.tar.gz 

40 [rdolmans@unbound ~]$ cd unbound-1.5.8 

41 [rdolmans@unbound unbound-1.5.8]$ ./configure 

42 [rdolmans@unbound unbound-1.5.8]$ make 

43 [rdolmans@unbound unbound-1.5.8]$ sudo make install 

44 

45 

46 # Add system user and group 
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47 [rdolmans@unbound unbound-1.5.8]$ sudo groupadd -r unbound 

48 [rdolmans@unbound unbound-1.5.8]$ sudo useradd -r -g unbound -s /sbin/nologin -c "unbound name 

49 daemon" unbound 

so 

51 

52# Setup unbound-control, get trust anchor 

53 [rdolmans@unbound ~]$ sudo unbound-control-setup 

54 [rdolmans@unbound ~]$ sudo unbound-anchor 


55 


56 


57# Config changes: 

58# 1. Specify the interfaces to listen on 

59# 2. Allow second host to use this resolver (ACL) 

60# 3. Load DNSSEC trust anchor obtained using unbound-anchor 

6 i# 4. Enable remote-control (for unbound-control command, limited to localhost) 

62 

63 

64 [rdolmans@unbound ~]$ diff -u /usr/local/etc/unbound/unbound.conf.orig /usr/local/etc/unbound/ 

65 unbound. conf 

66 -/usr/local/etc/unbound/unbound.conf.orig 2016-05-10 09:22:13.917495389 -0400 

67+++ /usr/local/etc/unbound/unbound.conf 2016-05-12 06:34:02.660574284 -0400 

68 @@ -34,6 +34,9 @@ 

69 # specify 0.0.0.0 and ::0 to bind to all available interfaces. 

70 # specify every interface[@port] on a new 'interface:' labelled line. 

71 # The listen interfaces are not changed on reload, only on restart. 

72+ interface: 192.168.3.98 

73 + interface: ::1 

74+ interface: 127.0.0.1 

75 # interface: 192.0.2.153 

76 # interface: 192.0.2.154 

77 # interface: 192.0.2.15405003 

78@@ -197,6 +200,7 @@ 

79 # access-control: ::0/0 refuse 

so # access-control: ::1 allow 

si # access-control: ::ffff:127.0.0.1 allow 

82 + access-control: 192.168.3.0/23 allow 


84 


86 


85 


# if given, a chroot(2) is done to the given directory. 

# i.e. you can chroot to the working directory, for example. 


87@@ -376,7 +380,7 @@ 


92 + 


88 


89 


90 


91 


# you start unbound (i.e. in the system boot scripts). And enable: 

# Please note usage of unbound-anchor root anchor is at your own risk 

# and under the terms of our LICENSE (see that file in the source). 

# auto-trust-anchor-file: "/usr/local/etc/unbound/root.key" 
auto-trust-anchor-file: "/usr/local/etc/unbound/root.key" 


93 


94 


95 


96 


# File with DLV trusted keys. Same format as trust-anchor-file. 
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97 # There can be only one DLV configured, it is trusted from root down. 

98 @@ -614,7 +618,7 @@ 

99 remote-control: 

100 # Enable remote control with unbound-control (8) here. 

101 # set up the keys and certificates with unbound-control-setup. 

io2- # control-enable: no 

103+ control-enable: yes 

104 

105 # Set to no and use an absolute path as control-interface to use 

106 # a unix local named pipe for unbound-control. 

107 

108 

109 # Start daemon 

no [rdolmans@unbound ~]$ sudo unbound-control start 

in 

112 

113# add local resolver to resolv.conf 

114 [rdolmans©unbound ~]$ echo "nameserver ::1" | sudo tee -a /etc/resolv.conf 

115 

116# Install ldns tools (incl. drill) 

117 [rdolmans@unbound ~]$ sudo yum install ldns 

118 


119 

120 # Test DNSSEC validation 

121 # 1. resolve bogus record with CD bit set, should result in answer 
122 # 2. resolve bogus record with CD bit unset, should result in SERVFAIL 


123 


124 # CD set: 

125 [rdolmans@unbound ~]$ drill txt bogus.nlnetlabs.nl @::1 -o CD 

126, *; -»HEADER«- opcode: QUERY, rcode: NOERROR, id: 36453 

127, *; flags: qr rd cd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2 
us;; QUESTION SECTION: 

i29,*; bogus.nlnetlabs.nl. IN TXT 

130 


131 

132,*; ANSWER SECTION: 

133 bogus.nlnetlabs.nl. 59 IN TXT "will be Bogus 

134 


135 


136,*; AUTHORITY SECTION: 


137 nlnetlabs . nl. 

138 nlnetlabs . nl. 

139 nlnetlabs . nl. 

140 nlnetlabs . nl. 


10200 

IN 

NS 

sec2.authdns.ripe.net 

10200 

IN 

NS 

anyns.pch.net. 

10200 

IN 

NS 

ns.nlnetlabs.nl. 

10200 

IN 

NS 

ns-extl.sidn.nl. 


141 

142,*; ADDITIONAL SECTION: 
143 ns.nlnetlabs.nl. 9831 IN 

144 ns.nlnetlabs.nl. 9831 IN 


A 185.49.140.60 

AAAA 2a04:b900::8:0:0:60 


145 


146 
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147;; Query time: 581 msec 
us;; SERVER: ::1 

149;; WHEN: Thu May 12 05:58:20 2016 
iso ; ; MSG SIZE rcvd: 209 

151 

152 

153 # CD unset: 

154 [rdolmans@unbound ~]$ drill txt bogus.nlnetlabs.nl @::1 
155;; -»HEADER«- opcode: QUERY, rcode: SERVFAIL, id: 14388 

156;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 
157;; QUESTION SECTION: 

158 ;; bogus.nlnetlabs.nl. IN TXT 

159 

160 ; ; ANSWER SECTION: 

161 

162,*; AUTHORITY SECTION: 

163 

164,*; ADDITIONAL SECTION: 

165 

166 ;; Query time: 0 msec 
167,*; SERVER: ::1 

168;; WHEN: Thu May 12 05:59:06 2016 
169;; MSG SIZE rcvd: 36 

170 

171 

172 

173#### 

174# NSD installation log for 10.33.XX.XX 

175 ### 

176 

177# Add 192.168.3.98 to resolv.conf 

178 [rdolmans@nsd ~]$ echo "nameserver 192.168.3.98" | sudo tee -a /etc/resolv.conf 

179 

180# install openssl, libevent 

181 [rdolmans@nsd ~]$ sudo yum install openssl-devel libevent-devel 

182 

183 # SoftHSM 

184 [rdolmans@nsd ~]$ tar xvzf softhsm-2.1.0 . tar. gz 

185 [rdolmans@nsd ~]$ cat softhsm-2.1.0 . tar. gz | openssl sha256 

186 (stdin)= 0399b06fl96fbfaebe73b4aeff2e2d65d0dcl901161513d0d6a94f031dcd827e 

187 [ rdolmans @nsd sof thsm-2.1.0 ] $ cd softhsm-2.1.0 

188 [rdolmans@nsd sof thsm-2.1.0 ] $ autoreconf -i -f 

189 # openssl version has no gost support, disable 

190 [rdolmans@nsd softhsm-2.1.0]$ ./configure --disable-gost 

191 [rdolmans@nsd softhsm-2.1.0] $ make 

192 [rdolmans@nsd sof thsm-2.1.0 ] $ sudo make install 

193 [rdolmans@nsdsofthsm-2.1.0]$ sudosofthsm2-util--init-token--slot0--label"OpenDNSSEC" 

194 

195# LDNS (incl. examples and drill) 
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196 [rdolmans@nsd ~]$ curl https://nlnetlabs.n1/downloads/ldns/ldns-l.6.17.tar.gz -o ldns- 

197 1.6.17 . tar. gz 

198 [rdolmans@nsd ~]$ cat ldns-1.6.17 . tar. gz | openssl shal 

199 (stdin)= 4218897b3c002aadfc7280b3f40cda829e05c9a4 

200 [rdolmans@nsd ~]$ tar xvzf ldns-1.6.17 . tar. gz 

201 [rdolmans@nsd ~]$ cd ldns-1.6.17 

202 [rdolmans@nsd ldns-1.6.17]$ ./configure --with-examples --with-drill 

203 [rdolmans@nsd ldns-1.6.17 ] $ make 

204 [rdolmans@nsd ldns-1.6.17] $ sudo make install 

205 

206 # OpenDNSSEC 

207 # install dependencies: SQLite3, libxml2, java (for now) 

208 [rdolmans@nsd ~]$ sudo yum install libxml2-devel sqlite-devel java-1.8.0-openjdk-devel 

209 [rdolmans@nsd ~]$ git clone https://github.com/opendnssec/opendnssec.git 

210 [rdolmans@nsd ~]$ cd opendnssec 

211 [rdolmans@nsd opendnssec] $ sh autogen. sh 

212 [rdolmans@nsd opendnssec] $ ./configure 

213 [rdolmans@nsd opendnssec] $ make 

214 [rdolmans@nsd opendnssec] $ sudo make install 

215 

216 

217 # Setup SQLite db 

218 [rdolmans@nsd opendnssec] $ sudo ods-enforcer-db-setup 

219 

220 # Use SoftHSM2, reload NSD zone after signing 

221 [rdolmans@nsd ~]$ sudo diff -u /etc/opendnssec/conf.xml.sample /etc/opendnssec/conf.xml 

222 -/etc/opendnssec/conf.xml.sample 2016-05-12 10:53:35.154584441 -0400 

223 +++ /etc/opendnssec/conf.xml 2016-05-17 12:03:20.719795941 -0400 

224 @@ -5,9 +5,9 @@ 

225 <RepositoryList> 

226 

227 <Repository name="SoftHSM M > 

228 - <Module>/usr/local/lib/softhsm/libsofthsm.so</Module> 

229 + <Module>/usr/local/lib/softhsm/libsofthsm2.so</Module> 

230 <TokenLabel>OpenDNSSEC</TokenLabel> 

231 - <PIN>1234</PIN> 

232 + <PIN>**********</PIN> 

233 <SkipPublicKey/> 

234 </Repository> 

235 

236 @@ -87,9 +87,7 @@ 

237 <!-- 

238 < NotifyCommand>/usr/local/bin/my_nameserver_reload_command</ 

239 NotifyCommand> 

240 --> 

241 “< ! -- 

242 - <NotifyCommand>/usr/sbin/rndc reload %zone</NotifyCommand> 

243 -> 

244+ <NotifyCommand>/usr/local/sbin/nsd-control reload %zone</NotifyCommand> 

245 </Signer> 
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246 

247 

248 </Conf iguration> 

249 

250 

251 # Add policy to KASP config file. We use a policy named dnslab here, which is based on policy 

252 default (but uses NSEC). 

253# See /etc/opendnssec/kasp. xml 

254 

255 [rdolmans@nsd ~]$ sudo ods-enforcer update all 

256 Created policy dnslab successfully 

257 Policy dnslab already up-to-date 

258 update all completed in 0 seconds. 

259 [rdolmans@nsd ~]$ sudo ods-enforcer policy list 

260 Policy: Description: 

26 1 dnslab Policy used for the NCCOE dnslab 

262 policy list completed in 0 seconds. 

263 [rdolmans@nsd ~]$ sudo ods-enforcer zone add --zone nevl.dnslab.nccoe.nist.gov --policy dnslab 

264 Zone nevl.dnslab.nccoe.nist.gov added successfully 

265 zone add completed in 1 seconds. 

266 


267 


268 


269 # NSD 

270 # Download, verify checksum, extract, configure, compile and install NSD 

271 [rdolmans@nsd ~]$ curl https://nlnetlabs.n1/downloads/nsd/nsd-4.l.9.tar.gz -o nsd-4.1.9.tar.gz 

272 [rdolmans@nsd ~] $ cat nsd-4.1.9 . tar. gz | openssl sha256 


273 (stdin)= b811224d635331de741f1723aefC41adda0a0a3a499ec310aa01dd3b4b95c8f2 

274 [rdolmans@nsd ~]$ tar xvzf nsd-4.1.9 . tar. gz 

275 [rdolmans@nsd ~]$ cd nsd-4.1.9 

276 [rdolmans@nsd nsd-4.1.9]# ./configure --with-pidfile=/var/run/nsd/nsd.pid 

277 [rdolmans@nsd nsd-4.1.9]$ make 

278 [rdolmans@nsd nsd-4.1.9]$ sudo make install 

279 [rdolmans@nsd ~]$ sudo nsd-control-setup 


281 # enable in config 

282 [rdolmans@nsd ~]$ sudo cp /etc/nsd/nsd.conf.sample /etc/nsd/nsd.conf 

283 [rdolmans@nsd ~]$ diff -u /etc/nsd/nsd.conf.sample /etc/nsd/nsd.conf 

284 -/etc/nsd/nsd.conf.sample 2016-05-17 11:46:58.379795464 -0400 

285 +++ /etc/nsd/nsd. conf 2016-05-18 07 : 06:14.861829191 -0400 

286 @@ -23,6 +23, 9 @@ 

287 # ip-address: 1.2.3.4 

288 # ip-address: 1.2.3.405678 

289 # ip-address: 12fe::8ef0 

290+ ip-address: 192.168.3.99 

291+ ip-address: ::1 

292+ ip-address: 127.0.0. 

293 # Allow binding to non local addresses. Default no. 

294 # ip-transparent: no 

295 0 0 - 62,7 + 65,7 @0 


DNS-Based Email Security Practice Guide 


111 




Chapter F. 


296 

297 # the database to use 

298 # if set to "" then no disk-database is used, less memory usage. 

299- # database: "/var/db/nsd/nsd.db" 

300+ database: "" 


301 

302 # log messages to file. Default to stderr and syslog (with 

303 # facility LOG_DAEMON). stderr disappears when daemon goes to bg. 

304 @@ -141,7 +144,7 @@ 

305 remote-control: 

306 # Enable remote control with nsd-control (8) here. 

307 # set up the keys and certificates with nsd-control-setup. 

308 - # control-enable: no 

309+ control-enable: yes 


310 


311 

312 

313 @@ 

314 

315 


# what interfaces are listened to for control, 

# control-interface: 127.0.0.1 
-249,4 +252,10 @@ 

# zonefile: "example.com.zone" 

# request-xfr: 192.0.2.1 example.com.key 


default is on localhost. 


316 


317 - 

318 +pattern: 


319 + 

320 + 

321 + 

322 +zone: 

323 + 

324 + 


name: "local-signed" 

zonefile: "/var/opendnssec/signed/%s" 


name: "nevl.dnslab.nccoe.nist.gov" 
include-pattern: "local-signed" 


325 


326 

327 [rdolmans@nsd ~]$ sudo groupadd -r nsd 

328 [rdolmans@nsd ~]$ sudo useradd -r -g nsd -s /sbin/nologin -c "nsd daemon" nsd 

329 

330 # Make user nsd the owner of the nsd db and run directories 

331 [rdolmans@nsd ~]# sudo chown nsd:nsd /var/db/nsd/ 

332 [rdolmans@nsd ~]# sudo chown nsd:nsd /var/run/nsd 

333 

334 # Start NSD 

335 [rdolmans@nsd ~]$ sudo nsd-control start 

336 

337 # Export DS 

338 [rdolmans@nsd ~]$ sudo ods-enforcer key export --zone nevl.dnslab.nccoe.nist.gov --ds 

339 ; ready KSK DS record (SHA1) : 

340 nevl.dnslab.nccoe.nist.gov. 3600 IN DS 35674 8 1 

341 7 9eele53ce23658b6d56322 97336b30 67a80e32 9 

342 ; ready KSK DS record (SHA256) : 

343 nevl.dnslab.nccoe.nist.gov. 3600 IN DS 35674 8 2 

344 0bd77d723e0a6d602a82bf0173a32a8286cfa4d602100e716192425544fb43a2 

345 key export completed in 0 seconds. 
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346 

347 

348 Generate key + self signed cert: 

349 

350 [rdolmans@unbound cert]$ sudo openssl req -newkey rsa:2048 -nodes \ 

351 -keyout nevl.dnslab.nccoe.nist.gov.key -x509 -days 365 -out nevl.dnslab.nccoe.nist.gov.crt 
352 Generating a 2048 bit RSA private key 


353 .+ + + 

354 .+ + + 


355 writing new private key to ' nevl. dnslab. nccoe . nist. gov. key' 

356 - 

357 You are about to be asked to enter information that will be incorporated into your certificate 

358 request. 

359 What you are about to enter is what is called a Distinguished Name or a DN. 

360 There are quite a few fields but you can leave some blank 

361 For some fields there will be a default value, 

362 If you enter ' the field will be left blank. 

363 - 

364 Country Name (2 letter code) [XX] :NL 

365 State or Province Name (full name) []: 

366 Locality Name (eg, city) [Default City] : Amsterdam 

367 Organization Name (eg, company) [Default Company Ltd] :NLnet Labs 

368 Organizational Unit Name (eg, section) []: 

369 Common Name (eg, your name or your server's hostname) []:nevl.dnslab.nccoe.nist.gov 

370 Email Address []: 

371 


372 

373# Generate TLSA record for cert: 

374 

375 [rdolmans@unbound cert]$ ldns-dane create nevl.dnslab.nccoe.nist.gov 25 3 1 1 -c 

376 nevl. dnslab. nccoe . nist. gov. crt 

377 _25._tcp.nevl.dnslab.nccoe.nist.gov. 3600 IN TLSA 3: 

378 1 1 0e8fOaf01ea3c87bb5647de3f36cd7ableedf5ae466edf5a8800f6174884f60d 


379 

380 # Add TLSA and MX records to zone: 


381 

382 [rdolmans@nsd unsigned]$ diff -u nevl.dnslab.nccoe.nist.gov.old nevl.dnslab.nccoe.nist.gov 

383 -nevl.dnslab.nccoe.nist.gov.old 2016-05-31 10:13:17.72837 9254 -0400 

384+++ nevl.dnslab.nccoe.nist.gov 2016-05-31 10:13:21.403379256 -0400 

385 @@ -9,7 +9,10 @@ 


386 

387 

388 

389 

390 + 

391 

392 

393 


NS ns.nevl.dnslab.nccoe.nist.gov. 

A 192.168.3.99 

MX 10 192.168.3.98 


TXT "dnslab test zone. 


394 


395 
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396 ns IN A 192.168.3.99 

397 + 

398 +_25._tcp IN TLSA 3 11 0e8fOaf01ea3c87bb5647de3f36cd7ableedf5ae466edf5a8800f6174884f60d 

399 

400 # Resign 

401 [rdolmans@nsd unsigned]$ sudo ods-signer sign nevl.dnslab.nccoe.nist.gov 

402 Zone nevl.dnslab.nccoe.nist.gov scheduled for immediate re-sign. 

403 
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.Appendix G Microsoft Installation for the 
NCCoE 


The following log captures the installation and configuration process for Microsoft system and 
applications software for the NCCoE's DNS-Based Email Security project. Please note that the IP 
addresses, domain names, and mail addresses are for the NCCoE laboratory and must not be 
used in actual implementations. 


,G.1 Microsoft Server 

8 Two Microsoft Active Directory domains were built for this project. MSl.DNSLAB.DNSOPS.GOV 

» and MS2.DNSLAB.DNSOPS.GOV domains. Two versions of Windows Server were used. 

o Windows Server 2016 Technical Preview 5, Standard GUI edition (WS2016TP5) which is 

available from the Microsoft Evaluation Center (https://www.microsoft.com/en-us/evalcenter/ 

2 evaluate-windows-server-technical-preview); and Active Directory Domain Services with 

3 integrated Domain Name Services and Certificate Services run on WS2016TP5. Currently, 

4 Exchange 2016 runs on Windows Server 2012R2 due to Exchange requirements (https:// 

s technet.microsoft.com/en-us/library/aa996719(v=exchg,160).aspx). 

6 The procession of Microsoft Services to be installed and configured is as follows: 

7 1. Active Directory Domain Services 

a 2. Active Directory Certificate Services - Root Certification Authority 

9 3. Active Directory Certificate Services - Issuing Certification Authority 

o 4. Active Directory Domain Name Services 

:i 5. Exchange 2016 


DNS-Based Email Security Practice Guide 


115 



Chapter G. 


192.168.1.0/24 

msl.dnslab.dnsops.gov 


Evl-dcl.msl.dnslab.dnsops.gov 



192.168.1.12 

• WS2016 TP5 

• ADDS 2016 

• DNS 2016 


g? 

dnslab.dnsops.gov 
DNS BIND 


192.168.2.0/24 

ms2.dnslab.dnsops.gov 


Ev2-dcl.ms2.dnslab.dnsops.gov 

192.168.2.12 

• WS2016TP5 

• ADDS 2016 

• DNS 2016 



Evl-root.msl.dnslabs.dnsops.gov 

192.168.1.13 

• WS2016 TPS 

• ADCS 2016 



Ev2-root.ms2.dnslabs.dnsops.gov 

192.168.2.13 

• WS2016 TP5 

• ADCS 2016 



Evl-issuing.msl.dnslabs.dnsops.gov 

192.168.1.14 

• WS2016 TP5 

• ADCS 2016 



Ev2-issuing.ms2.dnslabs.dnsops.gov 

192.168.2.14 

• WS2016 TP5 

• ADCS 2016 


Evl-exch.msl.dnslabs.dnsops.gov 
192.168.1.15 

• WS2012r2 

• Exchange 2016 

• Accepts mail for 
(Smsl.dnslab.dnsops.gov 
@1.msl.dnslab.dnsops.gov 
@2.msl.dnslab.dnsops.gov 

Evl-winlO.msl.dnslabs.dnsops.gov 
■ I 192 168 1 205 

“ • Windows 10 w/ virtual smart card 




Ev2-exch.ms2.dnslabs.dnsops.gov 

192.168.2.15 

• WS2012r2 

• Exchange 2016 

• Accepts mail for 

@ms2.dnslab.dnsops.gov 
@1. ms2.dnslab.dnsops.gov 
<5)2. ms2.dnslab.dnsops.gov 


Ev2-Winl0.ms2.dnslabs.dnsops.gov 

192.168.2.205 

• Windows 10 w/virtual smart card 


G.2 Active Directory Domain Services 

The following procedures were used for the creation of the MSl.DNSLAB.DNSOPS.GOV Active 
Directory domain on the EV1-DC1.MS1.DNSLAB.DNS0PS.GOV WS2016TP5 server. 

1. Statically assign IP address of the Domain Controller. This domain controller serves as the 
DNS server for the MSl.DNSLAB.DNSOPS.GOV Active directory domain: 

a. IP Address: 192.168.1.12 

b. Netmask: 255.255.255.0 

c. Gateway: 192.168.1.1 

d. DNS Server 192.168.1.12 

2. Install Active Directory Domain Services (ADDS) role: 

a. Server Manager -> Manage -> Add Roles and Features 

b. Installation type -> Role-based or feature based installation 

c. Server Selection -> local server 

d. Server Roles -> Select Active Directory Domain Services, accept the Features to be 
added with the installation of ADDS. 

e. On the Features selection menu click Next. 
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f. Click Install. 

g. Once installation is complete click Close. 

3. Configure the Active Directory Domain Services. 

a. In Server Manager click the exclamation mark underneath the flag icon and click on 

Promote this server to a domain controller. 

r 

i 


^ Post-deployment Configura... 

Configuration required for Active Directory Domain 
Services at EV1-DC1 

Promote this server to a domain controller 


b. Deployment Configuration -> Add a new forest and specify the root name of 
MSl.DNSLAB.DNSOPS.GOV. 


Active Directory Domain Services Configuration Wizard 


□ X 


Deployment Configuration 


TARGET SERVER 
evldcl 


Deployment Configuration 


Domain Cortroler Options 
Additional Options 
Paths 

Review Options 
Prerequisites Check 


Select the deployment operation 

O Add a domain controller to an existing domain 
O Add a new domain to an existing forest 
(§) Add a new forest 

Specify the domain information for this operation 

Root domain name: ms 1 .dnsiab.dnsops.gov 


Next > 


[ Cancel ] 


c. In Domain Controller Options select the defaults and set the Directory Services Restore 
Mode (DSRM) password. 

d. DNS Options - parent zone could not be found, click Next. 

e. The NetBios domain name will default to the lowest level of the FQDN of the Forest, i.e. 

MSI. 

f. Accept the default paths for the ADDS Database, Log and SysVol folders. If running on a 
virtual machine, follow the recommended practice of the virtualization host. 
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g. In the Prerequisites Check you will be notified that the DNS cannot be delegated. The 
DNS server will be hosted on this domain controller. 

G.3 Active Directory Certificate Services: Microsoft 
Certificate Authority 

Windows Server 2016 TP5 Active Directory Certificate Services (ADCS) serves as the Public Key 
Infrastructure for the MSl.DNSLAB.DNSOPS.GOV namespace. It is a two-tier hierarchy with 
EVl-ROOT.MSl.DNSLAB.DNSOPS.GOV as the root Certification Authority (CA) trust point, and 
EVl-ISSUING.MSl.DNSLAB.DNSOPS.GOV as the domain joined enterprise issuing CA. 


43 G.3.1 Root CA Installation 

«4 The installation of Active Directory Certificate Services must be performed by an enterprise 

« administrator. 

64 1. Copy CAPolicy.inf to the c:\windows directory: 

67 ; NCCoE DANE DNSSEC Building Block 

68 

69 [Version] 

70 Signature= "$Windows NT$" 

71 

72 ; Configures CA to allow only a single tier of CAs below it 

73 [BasicConstraintsExtension] 

74 PathLength = 1 

75 

76; Allows all issuance policies, sets HTTP pointer for CPS 

77 [PolicyStatementExtension] 

78 Policies = AlllssuancePolicy, LegalPolicy 

79 Critical = 0 

80 

si [AlllssuancePolicy] 

82 01D = 2.5.29.32.0 

83 

84 [LegalPolicy] 

85 01D = 1.1.1.1.1 

86 Notice = "http://pki.msl.dnslab.dnsops.gov/CPS.htm" 

87 URL = "http://pki.msl.dnslab.dnsops.gov/CPS.htm" 

88 

89; Sets key renewal and CRL publication parameters 

90 [Certsrv_Server] 

91 RenewalKeyLength = 4 0 96 

92 RenewalValidityPeriod = Years 

93 RenewalValidityPeriodUnits = 20 

94 CRLPeriod = days 

95 CRLPeriodUnits = 180 

96 CRLDeltaPeriodUnits = 0 
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97 CRLDeltaPeriod = days 

98 

99 ; Makes the CDP and AIA pointer for the root CA cert blank 

100 [CRLDistributionPoint] 

101 Empty = True 

102 

103 [AuthoritylnformationAccess] 

104 Empty = True 

105 

106 ; NCCoE DANE DNSSEC Building Block 

107 

108 [Version] 

109 Signature= "$Windows NT$" 

no 

in ; Configures CA to allow only a single tier of CAs below it 

112 [BasicConstraintsExtension] 

113 PathLength = 1 

114 

115 ; Allows all issuance policies, sets HTTP pointer for CPS 

116 [PolicyStatementExtension] 

117 Policies = AlllssuancePolicy, LegalPolicy 
ns Critical = 0 

119 

120 [AlllssuancePolicy] 

121 OID = 2.5.29.32.0 

122 

123 [LegalPolicy] 

124 OID = 1.1.1.1.1 

125 Notice = "http://pki .msl. dnslab .dnsops . gov/CPS .htm" 

126 URL = "http://pki.msl.dnslab.dnsops.gov/CPS.htm" 

127 

128 ; Sets key renewal and CRL publication parameters 

129 [Certsrv_Server] 

130 RenewalKeyLength = 4096 

131 RenewalValidityPeriod = Years 

132 RenewalValidityPeriodUnits = 20 
i33CRLPeriod = days 

134 CRLPeriodUnits = 7 

135 CRLDeltaPeriodUnits = 0 

136 CRLDeltaPeriod = days 

137 

138 ; Makes the CDP and AIA pointer for the root CA cert blank 

139 [CRLDistributionPoint] 

140 Empty = True 

141 

142 [AuthoritylnformationAccess] 

143 Empty = True 

144 
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145 

146 

147 

148 

149 

150 

151 

152 

mG.3.1. 

154 

155 


156 

157 

158 

159 

160 

161 

162 

163 

164 

165 

166 


2. Server Manager -> Manage -> Add Roles and Features. 

3. Installation type -> Role-based or feature based installation. 

4. Server Selection -> local server. 

5. Server Roles -> Select Active Directory Certificate Services, accept the Features to be 
added with the installation of ADCS. 

6 . On the Features selection menu click Next. 

7. Click Install. 

8 . Once installation is complete click Close. 

1 Configure Root CA 

1. Run post install configuration wizard, click on Configure Active Directory Certificate 
Services link: 


• ®i r A 

Manage 

■ 

A Post-deployment Configure... 

Configuration rccjuirsd for Active Directory 


Certificate Services at EV1-ROOT 

Configure Active Directory Certificate Services on th... 


Q Feature installation 


Configuration required. Installation succeeded on 
evl -rootmsl .dnsiabcfnsops.gov. 

Add Roles and Features 


Task Details 



2. Select Role Services to configure -> select Certification Authority. 

3. Setup Type = Standalone CA. 

4. CA Type = Root CA. 

5. Private Key = Create a new private key. 

6 . Cryptography: 

a. Cryptographic provider -> RSA#Microsoft Software Key Storage Provider 

b. Hashing Algorithm = SHA256 

c. Key Length 2048 

7. CA Name = EVl-Root 

8 . Once completed, run the post install script. 
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t67 : : NCCoE DANE DNSSEC Building Block 

168 

169 : : Declares configuration NC 

170 certutil -setreg CA\DSConfigDN CN=Configuration,DC=msl,DC=dnslab,DC=dnsops,DC=gov 

171 

172 : : Defines CRL publication intervals 

173 certutil -setreg CA\CRLPeriodUnits 7 

174 certutil -setreg CA\CRLPeriod "Days" 

175 certutil -setreg CA\CRLDeltaPeriodUnits 0 

176 certutil -setreg CA\CRLDeltaPeriod "Days" 

177 

178 : : Specifies CDP attributes 

179 certutil -setreg CA\CRLPublicationURLs 

iso"65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n6:http://pki.msl.dnslab.dnsops.gov/ 

181 %%3%%8%%9.crl\nl4:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n" 

182 

183 : : Specifies AIA attributes 

184 certutil -setreg CA\CACertPublicationURLs 

iss"1:%windir%\system32\CertSrv\CertEnroll\%%7.crt\n2:http://pki.msl.dnslab.dnsops.gov/ 

186 %%7.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%ll\n" 

187 

188 : : Enables auditing all events for the CA 

189 certutil -setreg CA\AuditFilter 127 

190 

191 : : Sets validity period for issued certificates 

192 certutil -setreg CA\ValidityPeriodUnits 10 

193 certutil -setreg CA\ValidityPeriod "Years" 

194 

195 : : Restarts Certificate Services 

196 net stop certsvc & net start certsvc 

197 

198 :: Republishes the CRL; sometimes this gets an access denied (error 5) because the service is not 

199 ready after restart, in this case, manually execute 

200 certutil -crl 


2 d G.3.1.2 Enable Certificate Services Auto Enrollment within the Active Directory Domain 

202 1. LogontothedomaincontrollerEVl-DCl.MSl.DNSLAB.DNSOPS.GOV. 

203 2. Start Group Policy Management console (gpmc.msc). 

204 3. Navigate to the Default Domain Policy. 

205 4. Within the Default Domain Policy go to Computer Configuration -> Policies -> Windows 

206 Settings -> Security Settings -> Public Key Policies 

207 5. Select the Certificate Services Client - Certificate Enrollment Policy setting. 

208 6. Set to Enabled, ensure the default Active Directory Enrollment Policy is selected and click 

209 OK. 
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a Group Policy Management 
v ^ Forest ms1.dnslab.dnsops.gov 
v ££ Domains 

v ms1.dnslab.dnsops.gov 
. Default Domain Policy 

> aj Domain Controllers 

> a3 Enterprise Accounts 

> £ Enterprise Servers 
2 Group Policy Objects 

, j WMI Fitters 

> ^ Starter GPOs 
> IQ Sites 

tj$t Group Policy Modeling 
S£ Group Policy Results 


Default Domain Policy 

Scope Deals Settings Delegation 



Links 



I £ Group Poficy Management Editor 

File Action View Help 

□ 

x r 

*4 a 5 a b B SB 




-• Default Domain Policy [EV1 -DC1.MS1.DNSIA8.DNS0PS.C 
v> jA. Computer Configuration 
v 2 Policies 

J Software Settings 
v 11 Windows Settings 

> |3 Name Resolution Policy 
Scripts (Startup/Shutdown) 
up Deployed Printers 
v Security Settings 
3 Account Policies 

> j Local Policies 
j Event Log 

_j Restricted Groups 
System Services 
^ Registry 

> ^ File System 

> (jf Wired Network (IEEE 8G2.3) Policies 

> ■ Windows Firewall with Advanced Secur 
33 Network List Manager Policies 

> Wireless Network (IEEE 802.11) Policies 

> 23 Public Key Policies 

> fl Software Restnction Policies 

> 22 Application Control Policies 

IP Security Policies on Active Directory 
23 Advanced Audit Policy Configuration 
Jy Policy-based QoS 

> 2] Administrative Templates: Policy definitions (A 
ii Preferences 
v jJ, User Configuration 

> 8 Policies 

> a Preferences 


Object Type 

23 Encrypting File System 
23 Data Protection 
1 BitLocker Drive Encryption 

J BitLocker Drive Encryption Network Unlock Certificate 
_] Automatic Certificate Request Settings 
2] Trusted Root Certification Authorities 
23 Enterprise Trust 

J Intermediate Certification Authorities 
21 Trusted Publishers 
23 Untrusted Certificates 
23 Trusted People 

Ir*! Certificate Services Client - Certificate Enrollment Policy 

13*1 Certificate Path Validation Settings 

I3ip Certificate Services Client - Auto-Enrollment 


Certificate Services Client - Certificate Enrollment Polic... ? 
Enrobnent Policy 

Configuration Model: Enabted 

Certificate enrolhent policy kst 

Default Name Automatic Enroftnent 

0 Active DrectoryEnrollmen... Enabled 


Addtonal certificate enroJment pokey configuration 
□ Disable user confined enrolment pokey servers 


H Canct( ***1 


7. Select Certificate Services Client - Auto-Enrollment setting. 
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^ Group Policy Management 
v Forest msl.dnslab.dnsops.gov 
v fn Domains 

v ms1.dnslab.dnsops.gov 
Default Domain Policy 

> aj Domain Controllers 

> Enterprise Accounts 
.. S3 Enterprise Sewers 

j Group Pokey Objects 
WMI Filters 

> Starter GPOs 
> 1$ Sites 

*(» Group Policy Modeling 
2-. Group Policy Results 


pA Computer Configuration 
v 2 Policies 

23 Software Settings 
v 23 Windows Settings 

> 21 Name Resolution Policy 
Scripts (Startup/Shutdown) 
ns Deployed Printers 
v Security Settings 

Account Policies 

> J Local Polrcies 

Event Log 

Jfj Restricted Groups 

> System Services 

> 4 Registry 

> la File System 

> jjiT Wired Network (IEEE 802.3) Policies 

> Q Windows Firewall with Advanced Secur 
13 Network List Manager Policies 

> U Wireless Network (IEEE 802.11) Policies 

Public Key Policies 

> O Software Restnction Policies 

> £3 Application Control Polrcies 

IP Security Policies on Active Directory 
22 Advanced Audit Policy Configuration 
£ Policy-based QoS 

> 23 Administrative Templates: Policy definitions (A 

> Q Preferences 
A User Configuration 

> S3 Policies 

3 Preferences 


Object Type 

23 Encrypting File System 
23 Data Protection 
J BitLocker Drive Encryption 

23 BitLocker Drive Encryption Network Unlock Certificate 
23 Automatic Certificate Request Settings 
2] Trusted Root Certification Authorities 
23 Enterprise Trust 

2 Intermediate Certification Authorities 
. J Trusted Publishers 
23 Untrusted Certificates 
iS Trusted People 

lyj Certificate Services Client - Certificate Enrollment Pokey 
'^Certificate Path Validation Settings 
W Certificate Services Client - Auto-Enrollment 


Default Domain Policy 

Scope Deals Settings Delegation 

Urdu 

I £ Group Pokey Management Editor 

File Action View Help 

a a W &\ B m 

/ Default Domain Policy [EV1-DC1 -MSI .DNSLAB.DNSOPSC 


Certificate Services Client-Auto-Enrollment Properties ? X 
Enrolment Policy Configuration 

Enrol user and computer certificates automatically 

Configuration Model: Enabfcd v 

Pi Renew expred certificates, update pendhg certificates, and remove 
revoked certificates 

0 Update certificates that use certificate templates 

Log expiry events and rfiow expiry notifications when the percentage of 
remamng certificate lifetime s 

i° Sj| % 

Additional stores. Use Y to sepa-ate multple stores. For example: 

"Store 1, Store!, Store3" 



I CX | Cancel Apply 


8 . Set Configuration Model to Enabled. 

9. Enable Renew Expired Certificates and Update certificates that use certificate templates 

radio buttons. 
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2 ,„G.3.2 Issuing a CA Installation 
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217 


218 

219 

220 


1. Start administrative command prompt as an Enterprise Administrator. 

2. Publish the EVl-Root CA certificate to Active Directory for dissemination to all systems 
within the MSl.DNSLAB.DNSOPS.GOV Active Directory domain. From an administrative 
command prompt, type certutil -dspublish -f evl-root.crt rootca. 


221 

222 


3. From the administrative command prompt, type certutil -pulse followed by gpupdate / 
force. 


4 . Copy CAPolicy.inf to the c:\windows directory. 


225 ; NCCoE DANE DNSSEC Building Block 


227 [Version] 

228 Signature= "$Windows NT$ 


230 ; Allows all issuance policies, sets HTTP pointer for CPS 

231 [PolicyStatementExtension] 

232 Policies = AlllssuancePolicy, LegalPolicy 

233 Critical = 0 


235 [AlllssuancePolicy] 

236 01D = 2.5.29.32.0 


238 [LegalPolicy] 

239 0ID = 1.1.1.1.1 

240 Notice = "http://pki .msl.dnslab.dnsops .gov/cps .htm" 

241 URL = "http://pki.msl.dnslab.dnsops.gov/CPS.htm" 


243 ; Sets key renewal and CRL publication parameters 

244 [ certsrv_server] 

245 renewalkeylength = 2048 

246 RenewalValidityPeriodUnits = 10 

247 RenewalValidityPeriod = years 

248 CRLPeriod = hours 

249 CRLPeriodUnits = 36 

250 CRLDeltaPeriod = hours 

251 CRLDeltaPeriodUnits = 0 

252 

253 5. Server Manager -> Manage -> Add Roles and Features. 

254 6 . Installation type -> Role-based or feature based installation. 

255 7. Server Selection-> local server. 

254 8. Server Roles -> Select Active Directory Certificate Services, accept the Features to be 

257 added with the installation of ADCS. 

25 a 9. Features = Certification Authority and Certification Authority Web Enrollment (this will 

259 add the required IIS features). 

260 1 0 . On the Features selection menu click Next. 
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11. Click Install. 

12. Once installation is complete click Close. 

13. Run the Post-Deployment configuration for the ADCS role. 
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Manage 

Post-deployment Configure¬ 
configuration required for Active Directory 

Certificate Services at EV1-ISSUING 

Configure Active Directory Certificate Services on th... 




14. Select both Certification Authority and Certification Authority Web Enrollment. 


6s AD CS Configuration — □ X 

DESTINATION SERVER 

Role Services evMssuing.ms1.dnslab.dnsops.gov 


Credentials 

Select Role Services to configure 

- - - - 

Setop 'ype 

@ Certification Authority 

CA Type 

@ Certification Authority Web Enrollment 


Online Responder 

Private Key 

Network Device Enrollment Service 


^rypiograpny 

CA Name 


Certificate Enrollment Web Service 
Certificate Enrollment Policy Web Service 


Certificate Request 
Certificate Database 
Confirmatior 


ore about AD CS Server Roles 


266 


< Previous Next > 


Cancel 


15. Setup Type = Enterprise CA 

16. CA Type = Subordinate CA 

17. Create new key (same as above). 

18. CA Name = EVl-lssuing 

a. Private Key = Create a new private key 

b. Cryptography: 

i. Cryptographic provider -> RSA#Microsoft Software Key Storage Provider 

ii. Hashing Algorithm = SHA256 
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iii. Key Length 2048 

19. Save the request file to the c:\ drive. 

20. Copy request file to root ca. 

21. On Root CA, issue certificate. 

22. Import evl-issuing.ca into the Certification Authority. 

23. Create a CNAME record for PKI.MSl.DNSLAB.DNSOPS.GOV to point to evl- 
issuing.msl.dnslab.dnsops.gov. 


1 DNS 
v | EV1-DC1 

v J3 Forward Lookup Zones 

Name 

Tl.msdcs 

Type 

Data 

Timestamp 

V 

1 .msdcs.msl.dnslab.d 
msl.dnslab.dnsops.g 

> 9 _msdcs 

> u3 .sites 

> 23 _tcp 

> fi udp 

□-tcp 
□ _udp 

^DomainDnsZones 
^ ForestDnsZones 
|| (same as parent folder) 

Start of Authority (SOA) 

[41[ evl-dcl.msl.dnslab.... 

static 


> j DomainDnsZonei 

[^(same as parent folder) 

Name Server (NS) 

evl • del .msl .dnslab.dnso... 

static 


> j ForestDnsZones 

[j (same as parent folder) 

Host (A) 

192.168.1.12 

8/19/2016 8.-00:00 AM 

V 3 

Reverse Lookup Zones 


Host (A) 

192.168.1.12 

static 


_ 1.168.192.in-addrarp 

f~l«v1-exch 

Host (A) 

192.168.1.15 

8/19/2016 12.-00:00 PM 


Trust Points 

IP] evl-issuing 

Host (A) 

192.168.1.14 

8/19/2016 IldJOrOO AM 


Conditional Forwarders 

evl-root 

Host (A) 

192.168.1.13 

8/19/2016 9dXk00 AM 



ripki 

Alias (CNAME) 

evl -issuing.msl dnslab.d... 

static 


24. Open Internet Information Service Manager. 

25. Go to the Default Web Site. 


285 26. Bindings: edit the existing default HTTP binding and add pki.msl.dnslab.dnsops.gov. 

286 27. Click on the Filter requests -> Select Allow File name Extension and add .crl, .crt and .cer. 

287 28. From an administrative command prompt type iisreset. 

288 29. On the Issuing CA run the post install script. 

289 : : NCCoE DANE DNSSEC Building Block 

290 

291 : : Declares configuration NC 

292 certutil -setreg CA\DSConfigDN CN=Configuration,DC=MS1,DC=DNSLAB,DC=DNSOPS,DC=GOV 

293 

294 : : Defines CRL publication intervals 

295 certutil -setreg CA\CRLPeriodUnits 3 

296 certutil -setreg CA\CRLPeriod "days" 

297 certutil -setreg CA\CRLDeltaPeriodUnits 0 

298 certutil -setreg CA\CRLDeltaPeriod "Hours" 

299 

300 : : Specifies CDP attributes 

301 certutil -setreg CA\CRLPublicationURLs 

302 "65:%windir%\system32\CertSrv\CertEnroll\%%3%%8%%9.crl\n6:http://pki.msl.dnslab.dnsops.gov/ 

303 %%3%%8%%9.crl\n79:ldap:///CN=%%7%%8,CN=%%2,CN=CDP,CN=Public Key Services,CN=Services,%%6%%10\n" 

304 

305 : : Specifies AIA attributes 
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306 certutil -setreg CA\CACertPublicationURLs 

307 "1:%windir%\system32\CertSrv\CertEnroll\%%7.crt\n2:http://pki.msl.dnslab.dnsops.gov/ 

308 %%7.crt\n3:ldap:///CN=%%7,CN=AIA,CN=Public Key Services,CN=Services,%%6%%ll\n" 

309 

310 : : Enables auditing all events for the CA 

311 certutil -setreg CA\AuditFilter 127 

312 

313 : : Sets maximum validity period for issued certificates 

314 certutil -setreg CA\ValidityPeriodUnits 5 

315 certutil -setreg CA\ValidityPeriod "Years" 

316 

317 : : Restarts Certificate Services 

3 18 net stop certsvc & net start certsvc 

319 

320 :: Republishes the CRL; sometimes this gets an access denied (error 5) because the service is not 

321 ready after restart, in this case, manually execute 

322 certutil -CRL 


G.4 Microsoft Domain Name Services: DNS Domain 
Server 

Active Directory Domain Services installation installs and configures the msl.dnslab.dnsops.gov 
Forward lookup zone. It is recommended to create a Reverse lookup zone for the subnets used. 


327 


a DNS Manager 

File Action View Help 

64 HE G B 


i a 


A DNS 
v | EV1-DC1 

v £3 Forward Lookup Zones 
> £/_ jnsdcs.msl.dnslab.d 
v ^ msl.dnslab.dnsops.g 
_msdcs 

> H .sites 

> 13 _tcp 

> S _udp 

> 0 DomainDnsZonei 

> 0 ForestDnsZones 
v ffl Reverse Lookup Zones 

1.168.192.m-addr.arp 
> J3 Trust Points 


Name 

[""|(same as parent folder) 
[”1(53me as parent folder) 
fl 192.168.1.12 
n 192.168.1.13 
fl 192.168.1.14 
D 192.168.1.15 


Type 

Start of Authonty (S0A) 
Name Server (NS) 
Pointer (PTR) 

Pointer (PTR) 

Pointer (PTR) 

Pointer (PTR) 


Data 


Timestamp 


(5], evl-dcl.msl.dnslab.d... 
evl-del .msl .dnslab.dnso.- 
ev1-dc1.ms1.dnslab.dnso... 
evl-root.msl.dnslab.dnso... 
evl-issuing.msl.dnslab.d... 
evl-exch.msl.dnslab.dnso... 


static 

static 

static 

8/19/2016 1:00:00 PM 
8/19/2016 1.-00:00 PM 
8/19/20161:00:00 PM 


1. Create a conditional forwarder for the other name spaces: 
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New Conditional Forwarder X 


DNSDomam: 

ms2.dnslab.dnsoos.gov 

1 _ 


IP addresses of the master servers: 

IP Acer ess 

Server FQDN 

validated 

Delete 

<ak* here to add a... 
0 192.168.2.12 

EV2-0C1 

The server with tf 

Up 

< 


> 



0 Store ths condttonal forwarder n Active Directory, and replicate it as fellows: 


Al DNS servers n this forest v J 

( This wil not repkcate to DNS servers that are pre-Wndows Server 2003 
“ doman controlers 

Number of seconds before forward guenes time out: j 5 

The server FQDN nil not be available if the appropriate reverse lookLp zones and entnes are not 
configured. 

OK j Cancel 


2. Create forwarded to dnslab.dnsops.gov. 


331 


g, DNS Manager 

File Action View Help 

**I«eIxbsbiiih| i a ta 


a DNS 
> 3 EV1-DC1 


Name 


EV1-DC1 Properties 


Debug Logging Event Logging Monitoring Security 
Interfaces Forwarders Advanced Root Hints 


Forwarders are DNS servers that this server can use to resolve DNS 
queries for records that this server cannot resolve. 


IP Address 
192.168.1.100 


Server FQDN 
< Unable to resolve > 


1^1 Use root hints if no forwarders are available 


Note: If conditional forwarders are defined for a given domain, they will be 
used instead of server-level forwarders. To create or view conditional 
forwarders, navigate to the Conditional Forwarders node in the scope tree. 




IP addresses of forwarding servers: 


e to add an IP Address or DNS Name: 


1 192.168.1.100 


<Unable to resolve > 


Number of seconds before forward queries time out: 3 


The server FQDN will not be available if the appropriate reverse lookup zones and entries are not 
configured. 


G.5 Microsoft Exchange 

Exchange 2016 was installed on a Windows Server 2012R2 Standard (Server with a GUI). 
Exchange 2016 is currently not supported on Windows Server 2016 Technical Preview 2016 

https://technet.microsoft.com/en-us/library/aa996719(v=exchg.l60).aspx. 

Exchange 2016 prerequisites can be found here: https://technet.microsoft.com/en-us/library/ 
bb691354(v=exchg,160).aspx. 
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Download for .Net 4.5.2: https://www.microsoft.com/en-us/download/details.aspx?id=42642. 


339 


340 


1. Install the Remote Tools Administration Pack using the following powershell command: 

Install-WindowsFeature RSAT-ADDS. 


2. Install Exchange 2016 prerequisites with the following powershell command: 


342 

343 

344 

345 

346 

347 

348 

349 

350 

351 


Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET- 
Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT- 
Clustering-Cmdlnterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, 
Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web- 
Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web- 
Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web- 
ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt- 
Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, 
Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, 
Windows-Identity-Foundation 


3. Perform Active Directory Schema update following the Technet article, "Prepare Active 
Directory and Domains": https://technet.microsoft.com/en-us/library/ 
bbl25224(v=exchg,160).aspx. 


4. Install the Mailbox role. 


MICROSOFT EXCHANGE SERVER 2016 SETUP 


9 


X 


Server Role Selection 


Select the Exchange server roles you want to install on this computer 
✓] Mailbox role 


Automatically install Windows Server roles and features that are required to install Exchange Server 


Qb Exchange 









5. Once the installation is completed go to the Exchange Admin console: https://evl- 

exch.msl.dnslab.dnsops.gov/ECP. 

6 . Create an Internet send connector following this Technet article: https:// 
technet.microsoft.com/en-us/libra ry/jj657457(v=exchg. 160).aspx. 

7. Create an SSL certificate for the Exchange services. 
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362 


363 


364 


365 


366 


8. On the Issuing CA (evl-issuing), open Certification Authority -> Certificate Templates. 

9. Right click -> Manage. 

10. Right click on the Web Server template and select duplicate. 

11. Compatibility = Windows Server Technical Preview 


3 Certificate Templates (evl-dcl.i 


Template Dit 
<31 CEP Encn 

3 Code Sigi 
3 Compute 
5 Cross Cer 
<31 Directory 
3 Domain ( 
<2 Domain C 
3EFS Reco' 
•2 Enrollmei 
3 Enrollmei 

2 Exchange 
<2 Exchange 
<2 Exchange 
3 IPSec 

3 IPSec (Of 
3 Kerberos 
3 Key Reco* 

3 OCSP Re; 
3 RAS and I 
3 Root Cert 
3 Router (C 

3 Smaitcan 
3 Smartcan 
3 Subordm 
3 Trust List 
3 User 
3 User Sign 
2 Web Serv 

.Si UU«rW*«»i 


Properties of New Template 


Subject Name Server issuance Requrements 

Superseded Templates Extensons Securty 

CompatibUty General Request Handing Cryptography Key Attestation 

The template options avaiabie are based on the earfest operating system 
versions set r CompauMty Settings 

0 Show resdbng changes 

Compatibly Settings 
Certification Authorty 

Windows Server Techncal Preview v 
Certificate recipient 

Windows Technical Preview / Wndows 


X * 
k 

m 


These settings may not prevent eater operatng systems from using this 
template. 


OK 


Cancel ~| Apply 


Help 


nn Arrtkanlmtir 


12. General -> Template Display Name MSI Web Server 
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• Properties of New Template X 

» 

SjOtect Name Server issuance Requrements 

Superseded Tenpates Extensions Securty 

Compatibtity General Request Handing Cryptography Key Attestation 


Template display name 



i Template name: 

' MSIWeb Server 


Validty period Renewal period: 

□ [ years v a weeks v; 

□ Publish certfcate in Active Directory 

Do net automabcaly re enrol t a duplicate certificate egoats in Active 
Directory 
I 

t 

i 


OK c;-, Help 


13. Security -> Domain Computers allowed to Enroll for certificate 


DNS-Based Email Security Practice Guide 


130 



















Chapter G. 


Properties of New Template X 

Subject Name Server Issuance Requirements 

Compatibly General Request Handing Cryptography Key Attestation 
Superseded Templates Extensons Secuty 

Group or user names 
Authentic atec Users 
J Adnsnetrator 

l£ Domain Adnsns (MSlVDoman Adrins) 

u. l | ||i ' | i 

l£ Enterprise Admins (MS 1 \Erterpnse Admns) 


Add.. Remove 


Permissions for Domain Computers 

Alow 

Deny 

Fufl Control 

□ 

□ 

Read 

a 

□ 

Wite 

□ 

□ 

Enrol 

0 

□ 

Autoenrol 

□ 

□ 


For apeaa permssons or advanced settings, cfcdc 
Advanced 


OK Cane© 


14. Subject Name -> Supply in Request 


Properties of New Template X 

Compatibly General Request Handing Cryptography Key Attestation 
Superseded Templates Extensons Seaxty 

Stijjed Name Server issuance Requirements 

(•) Supply m the request 

[—| Use subject nformabon from ewstng certificates for ai/.oenrol bent 
— renewal requests 

O &-* *ld from this Active Directory information 

Select the option to enforce conastency among subject names and to 
snp*fy certhcate administration 

Subject name foimal 

Mbi •: 

[ Indude email name n subject name 

Indude the rformation in alterrate subject name. 

[ E-maf name 
DNS name 

[_] User princpal name (UPN) 

[ Service principal name (SPN) 


OK 2ance .co;, Help 
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15. Click OK to save the new MSI Web Server certificate template. 

16. Back in the Certification Authority snap-in, right click on Certificate Templates -> Certificate 
to Issue, then select the MSI Web Server certificate template. 


376 


filccrt- 


File Action View Help 

*4 a I s »! b 


£j| Certification Authority (Local) 
v ^ EV1-ISSUING 

B Revoked Certificates 
B Issued Certificates 
B Pending Requests 
B Failed Requests 
Certificate Templates 


Name 

51 Directory Email Replication 
31 Domain Controller Auther 
3 Kerberos Authentication 
Al EFS Recovery Agent 
J Basic EFS 
31 Domain Controller 
31 Web Server 
3 Computer 

31 User 

31 Subordinate Certification t 
31 Administrator 


Intended Purpose 

Directory Service Email Replication 

■ Enable Certificate Templates X 

Select one Certificate Template to enable on thi Certfccation Authority 

Note If a ceitficate template that was recently created does not appear on this let. you may need to wat until 
rf cm at ion abotf the template has been replcated to all domain controlere 
Al of the certificate templates in the organisation may not be avertable to your CA. 

For more information, see Certificate Template Concepts. 


Name 

3] IPSec (Offline request) 

51 Key Recovery Agent 

Wended Pupose A 

IP secuty IKE rtemiedate 

Key Recovery Agent 

ML-n.-y— 


31OCSP Response Srgnmg 

OCSP Sgnmg 

a RAS yxf IAS Saver 

Clert Autherteation. Server Authentication 

31 Router (Offlne request) 

dent Authentication 

3] Smart card Logon 

dent Autherteation. Smart Card Logon 

31 Smart card User 

Seare Email. Qiert Authentication Smart Card Logon 

31 Trust List Sgnmg 

Mcrosoft Trust List Sgnmg 

31 User Signature Only 

Seccre Email. Qrert Authentication v 


OK | Cancel 


17. On the Exchange server (evl-exch), log on as an administrator and type certim.msc. 

18. Go to Personal -> Certificates -> right click -> request new certificate. 


379 


1 - 1 ° * 

hJ Certificate Enrollment 


Request Certificates 

You can request the following types of certificates. Select the certificates you want to request and then 
click Enroll. 


Active Directory Enrollment Policy 

Details v 

Details v 

nfigure settings. 


□ Show all templates 


□ Computer ^ STATUS: Available 

0 Ml Web Server STATUS: Available 

f\ f.'ore information is required to enroll for this certificate. Click here to co 


| Cancel ~~| 


Trusted Publishers 
Untrusted Certificates 
Third-Party Root Certificatior 




19. Subject Name: Common Name = evl-exch.msl.dnslab.dnsops.gov 

20. Alternative Name: DNS = evl-exch.msl.dnslab.dnsops.gov, msl.dnslab.dnsops.gov, 

1.msl.dnslab.dnsops.gov, 2.msl.dnslab.dnsops.gov 

21. Click OK and then select enroll. 

22. Use this certificate to protect the Exchange services. 

23. Within the Exchange Admin console (https://evl-exch.msl.dnslab.dnsops.gov/ECP), select 
Server -> Certificates, then change all services to use the issued SSL certificate. 
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servers databases database availability groups virtual directories ^ certi fi cate d 


Select server | evl -exch.msl .dnslab.dnsops.gov 


+ / HO C — 


NAME 

STATUS 

EXPIRES ON * 




8/19/2018 

Exchange SSL 

Microsoft Exchange Server Auth Certificate 

Valid 

8/5/2021 

Microsoft Exchange 

Valid 

8/31/2021 

Certification authority-signed certificate 

Issuer CN=EV1-ISSUING. DC=ms1, DC=dnslab, DC=dnsops, DC=gov 

WMSVC 


8/17/2026 

Status 

Expires on: 8/19/2018 

Renew 

Assigned to services 

NONE 


388 




Exchange Certificate - Internet Explorer 


https7/ev1-exch.msl.dnslab.dnsops.gov ecp/CertMgmt/EditCertificate.aspx?pwrncid=38iReturnObjectType= 1&id=ev1-exch.msl.dnsla £ 


Exchange SSL 

► generaj 


Name: 

(Exchange SSL 


(Valid 

Issuer 


|CN=EV1-ISSUING, DC=ms1, DC=dnslab, DC=dnsops, DC=gov 

Expires on: 


|s/19/2018 

Subject 


|CN=ev1 -exch.dnslab.dnsops.gov 

Subject Alternative Names: 


evl ex charts la b-dnsops^jov 


ms1.dnslab.dnsops.gov 
1 .msl .dnslab.dnsops.gov 
2.ms1 .dnslab.dnsops.gov 


Thumbprint: 

(CDE061915589A82EA0B1FCD915469188D4D030CB 

Serial number. 


|32000000088AD81 A5M7E1AC0C000100000008 

Public key size: 

|io4i 

Has private key. 


24. Select all the services except for Unified Messaging. 
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390 


'S 


Exchange Certificate - Internet Explorer 


-4e https, evl-exch.msl.dnslab.dnsops.gov ecp/CertMgmt/EditCertificate.aspx?pwmcid= 3&ReturnObjectType= 1 &id= evl-exch.msl.dnsla A 


Exchange SSL 

general 
► services 


Specify the services you want to assign this certificate to. Learn more 
0 SMTP 

I | Microsoft Exchange Unified Messaging 
I | Unified Messaging Call Router 
0 IMAP 
0 POP 

0 ns 


Save 

Cancel 



^ 100 % 


391 G. 5.1 Generate the TLS DNS Record 


1. Sign the msl.dnslab.dnsops.gov zone by following the Technet article for enabling DNSSEC 

https://technet.microsoft.com/en-us/library/hh831411.aspx. 

2. Export the Exchange SSL certificate to a .cer file. Find the certificate on the Issuing CA (evl- 
issuing) within the Issued Certificates group. 
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396 


Certification Authority (Local) 
v EV1 -ISSUING 

□ Revoked Certificates 
j Issued Certificates 

l 3 Pending Requests 
j Failed Requests 

□ Certificate Templates 


Request ID 

Requester Name 

Binary Certificate 

Certificate Template 

[^4 

MS1\EV1-DC1S 

. BEGIN CERTI... 

Domain Controller (... 

E35 

MS1\EV1-DC1$ 

.BEGIN CERTI... 

Directory Email Repli... 

ge 

MS1\EV1-DC1S 

. BEGIN CERTI... 

Domain Controller A... 

mi 

MS1\EV1-DC1S 

.BEGIN CERTI... 

Kerberos Authenticat... 

[**38 

MS1\EV1-EXCHS 

.BEGIN CERTI... 

Ml Web Server (1.3.6... 


r Certificate 

General Details Certification Path 


X 


Show: <AII> 


Field 

^[version 
j Serial number 
_| Signature algorithm 
J Signature hash algorithm 
J Issuer 
_l] Valid from 
[ill Valid to 
riilciibigrr 


Value 

V3 

32 00 00 00 08 8a d8 la 5a 47... 

sha256RSA 

sha256 

EVl-ISSUING, msl, dnslab, dn... 
Friday, August 19, 2016 2:43:... 
Sunday, August 19, 2018 2:4... 

ow 1 -ovi-h rindah Hncnnc nrtst 


Edit Properties... 


Copy to File... 


OK 


3. Click on the Details tab and select Copy to File. Save as a base64 (.cer) file. 
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7^1 Certification Authority (Local) 
v ^ EV1-ISSUING 

n Revoked Certificates 
Issued Certificates 
Cl Pending Requests 
j Failed Requests 
□ Certificate Templates 


Request ID 

Requester Name 

Binary Certificate 

Certificate Template 

Serial Number Certificate Effective Date 

Certificate Expiration Date 

m 

MS1XEV1-DC1S 

-BEGIN CERTI... 

Domain Controller (... 

3200000004720... 8/19/20161:16 PM 

8/19/20171:16 PM 


MS1\EV1-DC1S 

.BEGIN CERTI... 

Directory Email Repli... 

3200000005d99... 8/19/20161:17 PM 

8/19/20171:17 PM 

L*l6 

MS1VEV1-DC1S 

.BEGIN CERTI... 

Domain Controller A,.. 

3200000006fd4... 8/19/20161:17 PM 

8/19/20171:17 PM 

mi 

MS1VEV1-DC1S 

.BEGIN CERTI... 

Kerberos Authenticat... 

3200000007fc2... 8/19/20161:17 PM 

8/19/20171:17 PM 

E*l8 

MS1XEV1-EXCHS 

.BEGIN CERTI... 

Ml Web Server (13.6... 

32000000088ad... 8/19/20162:43 PM 

8/19/20182:43 PM 


Q Certificate 

General Details Certification Path 
Show: <AI> 


Reid 

Value A 

diversion 

V3 

d Serial number 

32 00 00 00 08 8a d8 la 5a 47... 

□ Signature algorithm 

sha256RSA 

I J Signature hash algorithm 

sha256 

[ | Issuer 

EV 1-ISSUING, msl, dnslab, dn... 

□ Valid from 

Friday, August 19, 2016 2:43:... 

□ valid to 

Sunday, August 19, 2018 2:4... 

Flq.iFrio.-t 

01,1 -ovrh Hnciah Hnmrx nnw ^ 


Copy to File... 


<- *■ Certificate Export Wizard 


Select the format you want to use: 

O DER encoded binary X. 509 (,CER) 

(•) Base-64 encoded X. 509 (.CER) 

O Cryptographic Message Syntax Standard - PKCS #7 Certificates (.P7B) 
Indude all certificates m the certification path if possible 
C 1 Personal Information Exchange - PKCS #12 (.PFX) 

Indude all certificates m the certification path if possible 
Delete the private key if the export is sc 
0 Export all extended properties 
EH Enable certificate privacy 
Microsoft Serialized Certificate Store (.SST) 


[ Next | Cancel | 


4. Go to https://www.huque.com/bin/gen_tlsa. Open the exported certificate into notepad, 
the copy and paste into the Enter/paste PEM format X.509 certificate here field. 

5. Fill in the name space specific information. 


402 


O 


fij https://wvw.huque.com/bin/gen_tlsa P - flC H Generate TLSA Record 


Generate TLSA Record 

Generate DNS TLSA resource record from a certificate and given parameters. 

Usage Field: 

O 0 - PKIX-TA: Certificate Authority Constraint 
01 - PKIX-EE: Service Certificate Constraint 
02 - DANE-TA: Trust Anchor Assertion 
® 3 - DANE-EE: Domain Issued Certificate 

Selector Field: 

OO - Cert: Use full certificate 
® 1 - SPKI: Use subject public key 

Matching-Type Field: 

OO - Full: No Hash 
® 1 - SHA-256: SHA-256 hash 
02 - SHA-512: SHA-512 hash 

Enter/paste PEM format X.509 certificate here: 

ZXM3Q04 9U2Vydral3 ZXM3Q04 9Q29uZralndXJhdGlvblxEQzltczE3REM9ZG5zbGFl 
LERDPWRuc29wcyxEGzlnb3Y/Y0FDZXJ0aWZpV2F0ZT9iVXNlP29ianiVjdENsYXNz A 
PWNlcnRpZml:) YXRpb25BdXRob3 JpdHkwDQYJKoZIhvcNAQELBQADggEBAJcj4pwl 
3vre£DEHS+SeytJIKJzIk£K12MdWR/lcXFUMqlI.I.Ot+bp]c298£rg/F71D7IyihgQI.W 
Y0o3rQUIW6c27e3AeWzWxlc/ 4uHcweUzS j IcJwLlLClYoZOgBlhZP jHsYPPBG7fcW0c 
4/i7CdIFE51WgsmweQpZaOGqd3reAvXuaqMiceCoBccxosQIz2TXVb1cxDAmWcVGiG 
9H0tvk4DSE+My+91O£q84L+ewouV5FD5Rxdpi!)YNpzAEYn70pybgQlTB+WX9Ilz£ 
hNq4mHRd5yNht vDKhYeDIXn4udCbNi9pY3 onPlAQi+EKDj dtatvf 9E0GFWyc 6GMG 
gS7FccQ5awafqr4= v 

-END CERTIFICATE- 


Port Number: |443 | (e.g. 44 3) 

Transport Proto col: |tcp ] (e.g. tcp, udp, sctp, deep) 
Domain Name: |ms1 .dnslab.dnsops.gov 


Other DANE Tools 


x^aj _ a £ 

File Edit Format View Help 

-BEGIN CERTIFICATE- A 

MIIGlzCC8X+gAwIBAgITMgAAAAiK2BpaR+GsDAABAAAACDANBgkqhkiG9w0BAQsF 
ADBwMRMwEQYKCZImiZPyLGQBGRYDZ292MRYwFAYKCZImiZPyLGQBGRYGZG5zb3Bz 
MRYwFAYKCZIniZPyLGQBGRYGZGSzbGFiMRMwEQYKCZImiZPyLGQBGRYDbXMxMRQw 
EgYDVQQDEwtFVjEtSVNTVUlORzAeFw0xNjA4MTkyMTQzMjZaFw0xODA4MTkyMTQz 
MjZaMCUxIzAhBgNVBAMTGmV2MSlleGNolmRuc2xhYiSkbnNvcHMuZ292MIIBIjAN 
BgkqhkiG9w0BAQEFAAOCAQ8AHIIBCgKCAQEAoNZWTKL4ShwC2caylZHIuqMjdKlB 
UVwiezV0N9orlAGSrPtIdHuSkUTC+49K28VFzdq9ZwRGhdL3TXV9Al+SoyYGFmyc 
itnNboF5p5Ed+t30ZlgnxSjvT/DF+jqfMpI375RH33RqFSkclP/IUgR9KMjYWGOC 
foQiCrxuWhWpPc0RNITKgH/39/sMfNigIlUSMS0XAZlBiVUMh+3f2HWFdqaiza8Z 
YW92zg/dX/af28Ep/Rld/BNN31tCOOom3eLlqrLP4IKOfK13G10w6bgrKL13V7DS 
RmBdybXazfCeWckjGV»50RqbGHlA2efxSgqSXzLo90YlOYrizmve6B10dwIOAQAB 
04IDczCCA28wPAY3KwYBBAGCNxUHBC8wlQYlKwYBBAGCNxUIh7X9H0TR8CTRgSeB 
+rxSger4dQWH/4V8gpHFCwIBZAIBAzAT6gNVHSUED0AKBggrBgEFBQcDATA0BgNV 
HQ8BAf8EBAMCBaAwGwY3KwYBBAGCNxUKBA4wODAKBggr'BgEFBQcDATAdBgNVHQ4E 
FgQUltj+A+cHldUBGOblr5BzAOievRIwbgYDVR0RBGcwZYIaZXYxLWV4Y2guZG5z 
bGFilmRuc29wcy5nb3aCFWlzMS5kbnNsYWIuZG5zb3BzLmdvdoIXMS5tczEuZG5z 
bGFiLnRuc29wcy5nb3aCFzIubXMxLi»Ruc2xhYi5kbnNvcHMuZ292MB8GAlUdIwQY 
M8aAFInQ8gNwi«KVSopiwFTiiScYYCPEGHIIBHwYDVR0fBIIBFjCCARIwggEOoIIB 
CqCCAQaGO2h0dHA6Ly9wa2kubXHxLi»Ruc2xhYi5kbnNvcHMuZ292L2NlcnRlbn3v 
bGwvRVYxLUlTUlV3TkcuY33 shoHGbGRhc0ovLy90TjlFVj EtSVNTVUlORyxDTj11 
djEtaXNzdWluZyxDTjlDRFAsQ049UHVibGlj3TIwS2V53TIwU2VydmljZXMsQ049 
U2VydtiljZXMsQ049Q29uZmlndX3hdGlvbixEQzltczEsREM9ZG5zbGFiLERDPWRu 
c29wcyxEQzlnb3Y/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj 
dENsYXNzPWNSTERpc3RyaW31dGlvblBvaW50MIIBGAYIKwYBBQUHAQEEggEKMIIB 
BjBHBggrBgEFBQcwAoY7aHR0cOovL3BraS5tczEuZG5zbGFiLoiRuc29wcySnb3Yv 
Y2VydGVucn9sbC9FVjEtSVNTVU10Ry5jcnQwgboGCCsGAQUFBzAChoGtbGRhcDov 
Ly9DTjlFVj EtSVNTVUlORyxDT jlBSUEsQ049UHVibGlj]TIwS2V5DTIwU2Vydralj 
ZXMsQ049U2VydnljZXMsQ049Q2|3uZmlndX3hdGlvbixEQzltczEsREM9ZG5zbGFi 
LERDPWRuc29wcyxEQzlnb3Y/Y0FDZX30aWZpY2F0ZT9iYXNlP29iamVjdENsYXNz 
PWNlcnRpZnljYXRpb25BdXRob33pdHkwOQY3KoZIhvcNAQELBQADggEBA3cj4pwl 
3vrefDEHS+SeyUIK3zIkfK12MdWR/kXFUMqlLLOt+bpk298frg/F71D7IyihgQLW 
Y0o3rQUIW6t27esAeWzWxk/4uHtweUzSjk3wLiLClYoZ0gBihZPjHsYPPBG7bWOc 
4/i7CdIFE51WgsnweQpZaUGqdjreAvXuaqMkeCoBtcxosQIz2TXVbkxDAmWcVGiG 
9HOtvk4DSE+My+91Ofq84L+ewouV5FO5RxdpihYNpzAEYn70pybgQlTB+WX9Ilzf 
hNq4nHRd5yNhtv0KhYeDIXn4udCbNi9pYjcnPlAQi+rKDjdtatvf9E0GFWyt6GMG 
gS7FtcQ5awafqr4= 

-END CERTIFICATE- 


403 6. Select Generate and the TLSA record string is presented back. 

404 443._tcp.msl.dnslab.dnsops.gov. IN TLSA 3 11 

405 25d645a7bd304ae552c629ca5e7061a70f921afc4dd49clea0c8f22de6595be7 
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flu 


Generate TLSA Record 

Generate DNS TLSA resource record from a certificate and given parameters. 

Certificate Information: 

Serial: 32000000088ad81a5a47e1ac0c000100000008 

Issuer: DC=gov, DC=dnsops, DC=dnslab, DC=ms1, CN=EV1-ISSUING 

Subject: CN=ev1 -exch.dnslab.dnsops.gov 

Subject Alternative Name(s): DNSevI-exch.dnslab.dnsops.gov, DNS:ms1 dnslab.dnsops.gov, DNS1ms1.dnslab.dnsops.gov, DNS:2.ms1.dnslab.dnsops.gov 
Certificate Inception: 2016-08-19 21:43:26+00:00 UTC 
Certificate Expiration: 2018-08-19 21:43:26+00:00 UTC 

TLSA Parameters: 

Usage: 3 - DANE-EE: Domain Issued Certificate 
Selector: 1 - SPKI: Subject Public Key 
Matching Type: 1 - SHA-256: SHA-256 Hash 

Service Parameters: 

Port: 443 
Transport: tcp 

Domain name: msl dnslab.dnsops.gov. 

Generated DNS TLSA Record: 



406 


(Generate another TLSA record?) 


407 7. To register this TLSA record within Windows Server 2016 Active Directory Domain Name 

4 os Services, issue the following powershell command on the Domain Controller as 

409 Administrator: 

4 10 add-dnsserverresourcerecord -TLSA -CertificateAssociationData 

4 11 "25d645a7bd304ae552c629ca5e7061a70f921afc4dd49clea0c8f22de6595be7" - 

412 CertificateUsage DomainlssuedCertificate -MatchingType Sha256Hash -Selector 

413 FullCertificate -ZoneName msl.dnslab.dnsops.gov -Name _25._tcp.evl- 

4 1 4 exch.msl.dnslab.dnsops.gov. 

415 8. To get the zone output, issue the following powershell command: 

4 1 6 Resolve-DnsName evl-dcl.msl.dnslab.dnsops.gov -type soa -server evl-dcl - 

417 DnssecOk 


4 ,aG.5.2 Issue S/MIME Certificates and Configure Outlook 

419 To issue an S/MIME Digital Signature certificate to the user, go to the Issuing CA (evl-issuingca). 

420 1. Open the Certification Authority snap-in, right click on Certificate Templates and select 

421 Manage. 

422 2. Find the Exchange Signature Only certificate template, right click and select duplicate. 

423 3. Set Compatibility to Windows Server 2012 R2. 
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D Certificate Templates Console 


Bl B m 


Template Display Name 
Code Signing 
<11 Computer 

<! Cross Certification Authority 

m Directory Email Replication 

<U Domain Controller 

■ill Domain Controller Authentication 

<H EFS Recovery Agent 

<1! Enrollment Agent 

ill Enrollment Agent (Computer) 

t!] Exchange Enrollment Agent (Offline requ... 

<H Exchange Signature Only 

4*3 Exchange User 

<1 IPSec 

CH IPSec (Offline request) 
iU Kerberos Authentication 
tU Key Recovery Agent 
iU Ml Web Server 
<U OCSP Response Signing 
<U RAS and IAS Server 
M Root Certification Authority 
<13 Router (Offline request) 

<13 Smartcard Logon 
<U Smartcard User 

<U Subordinate Certification Authority 
<U Trust List Signing 
<1 User 

<U User Signature Only 
m Web Server 

<11 Workstation Authentication 


Schema Version 
1 


Ver* / 

B.1 


Certificate Templates (evl -del .msl .dnslab.dnso... ^ 


Properties of New Template X 

Subject Name Server Issuance Requirements 

Superseded Templates Extensions Security 

Compatibility General Request Handling Cryptography Key Attestation 

The template options available are based on the earliest operating system 
versions set in Compatibility Settings. 

pi Show resulting changes 

Compatibility Settings 
Certification Authority 


Windows Server 2012 R2 


Certificate recipient 


Windows 8 / Windows Server 2012 


These settings may not prevent eariier operating systems from using this 
template. 


Cancel 


Apply 


4. Within the General tab provide a name for the new template. 


U Certificate Templates Console 

File Action View Help 


*41 rail li!Bn 


U Certificate Templates (evl-del.r 


Template Display Name 
HJ Code Signing 
■13 Computer 

<U Cross Certification Authority 

m Directory Email Replication 

m Domain Controller 

<U Domain Controller Authentication 

<U EFS Recovery Agent 

m Enrollment Agent 

■13 Enrollment Agent (Computer) 

Exchange Enrollment Agent (Offline requ... 
<U Exchange Signature Only 
a Exchange User 
a IPSec 

a IPSec (Offline request) 
a Kerberos Authentication 
a Key Recovery Agent 
a Ml Web Server 
a OCSP Response Signing 
a RAS and IAS Server 
a Root Certification Authority 
a Router (Offline request) 
a Smartcard Logon 
a Smartcard User 

a Subordinate Certification Authority 
a Trust List Signing 
a User 

a User Signature Only 
a Web Server 

a Workstation Authentication 


Schema V 
1 
1 
2 
2 
1 
2 
1 
1 
1 
1 


Ver; / 
3.1 


Certificate Templates (evl -del .msl .dnslab.dnso... 


Properties of New Template X 

Subject Name Server Issuance Requirements 

Superseded Templates Extensions Security 

Compatibility General Request Handling Cryptography Key Attestation 

Template display name: 

I MSI SMIME DigSigl 


Template name: 
[MSISMiMEDigSig 


Validity period: 


[~~| Publish certificate in Active Directory 

Do not automatically reenroll if a duplicate certificate exists in Active 
Directory 
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428 


5. In the Cryptography tab select Request can use any provider available on the subject's 
computer. 


D Certificate Templates Console 

File Action View Help 


si B Bl B a 


10 Certificate Templates (evl-del.r 


Template Display Name 
dU Code Signing 
tl] Computer 

<H Cross Certification Authority 

*S] Directory Email Replication 

dU Domain Controller 

M Domain Controller Authentication 

tH EFS Recovery Agent 

d! Enrollment Agent 

d!3 Enrollment Agent (Computer) 

dO Exchange Enrollment Agent (Offline requ... 

H Exchange Signature Only 

m Exchange User 

<13 IPSec 

<U IPSec (Offline request) 
dH Kerberos Authentication 
d!3 Key Recovery Agent 
dU Ml Web Server 
d!3 OCSP Response Signing 
dU RAS and IAS Server 
dU Root Certification Authority 
tU Router (Offline request) 
d!3 Smartcard Logon 
m Smartcard User 

dU Subordinate Certification Authority 
dU Trust List Signing 
dl] User 

d0 User Signature Only 
-U Web Server 

di Workstation Authentication 


Schema V 
1 
1 
2 
2 
1 
2 
1 
1 
1 
1 
1 
1 
1 
1 
2 
2 
4 
3 
2 
1 
1 
1 
1 
1 
1 
1 
1 
1 
2 


Ver: / 
3.1 


Certificate Templates (evl-dcl.msl.dnslab.dnso... 


Properties of New Template X 

Subject Name Server Issuance Requirements 

Superseded Templates Extensions Security 

Compatibility General Request Handling Cryptography Key Attestation 


Provider Category: 


Minimum key size: 


Legacy Cryptographic Service Provider 


Determined by CSP 


12048 


Choose which cryptographic providers can be used for requests 
(•) Requests can use any provider available on the subject's computer 
O Requests must use one of the following providers: 

Providers: 


@ Microsoft Base Cryptographic Provider vl .0 
@ Microsoft Base Smart Card Crypto Provider 
□Microsoft Enhanced RSAand AES Cryptographic Provider 
□Microsoft Strong Cryptographic Provider 


Request hash: Determined by CSI 

Use alternate signature format 


Apply 


6 . In the Security tab, select Authenticated Users from Group or user names, and allow Read 
and Enroll. 
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13 Certificate Templates Console 

File Action View Help 


♦ 41 hIHBI H h 


H Certificate Templates (evl-del.r 


Template Display Name 
■U CodeSigning 
51 Computer 

Cross Certification Authority 
Directory Email Replication 
rU Domain Controller 
51 Domain Controller Authentication 
5] EFS Recovery Agent 
5] Enrollment Agent 
51 Enrollment Agent (Computer) 
tiH Exchange Enrollment Agent (Offline requ... 
5] Exchange Signature Only 
m Exchange User 

5] IPSec 

5] IPSec (Offline request) 

51 Kerberos Authentication 
51 Key Recovery Agent 
51 Ml Web Server 
tl] OCSP Response Signing 
51 RAS and IAS Server 
51 Root Certification Authority 
53 Router (Offline request) 

51 Smartcard Logon 
53 Smartcard User 

51 Subordinate Certification Authority 
tl] Trust List Signing 

51 User 

51 User Signature Only 
tU Web Server 

51 Workstation Authentication 


Schema Version 


Ver« A 
3.1 


Certificate Templates (evl-dcl.msl.dnslab.dnso... 


Properties of New Template X 

Subject Name Server Issuance Requirements 

Compatibility General Request Handling Cryptography Key Attestation 
Superseded Templates Extensions Security 

Group or user names: 


fit Authenticated Users 
2 Paul Fox (j 3 fox@msl .dnslab.dnsops.gov) 
fit Domain Admins (MSlVDomain Admins) 
fit Enterprise Admins (MSIXEnterprise Admins) 


Permissions for Authenticated Users 

Allow 

Deny 

Full Control 

□ 

□ 

Read 

0 

□ 

Write 

□ 

□ 

Enroll 

0! 

□ 

Autoenroll 

□ 

□ 


For special permissions or advanced settings, dick 
Advanced. 


7. In the Subject Name tab, select Build for this Active Directory information -> Email name 

(note: make sure the mail attribute on the recipient's Active Directory object is populated 
with the correct email address) 
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ID Certificate Templates Console 


□ X 


File Action View Help 

Hi H SI B n 


1 


Certificate Templates (evl-dcl.r 


Template Display Name 


HI Code Signing 
HI Computer 

HI Cross Certification Authority 

HI Directory Email Replication 

HI Domain Controller 

•il] Domain Controller Authentication 

HI EFS Recovery Agent 

hi Enrollment Agent 

■dll Enrollment Agent (Computer) 

HI Exchange Enrollment Agent (Offline requ... 
HI Exchange Signature Only 
HI Exchange User 
ll IPSec 

tU IPSec [Offline request) 

<1 Kerberos Authentication 
HI Key Recovery Agent 
HI Ml Web Server 
M OCSP Response Signing 
HI RAS and IAS Server 
HI Root Certification Authority 
HI Router (Offline request) 

HI Smartcard Logon 
HI Smartcard User 

HI Subordinate Certification Authority 
HI Trust List Signing 
HI User 

HI User Signature Only 
HI Web Server 

'HI Workstation Authentication 


Schema Version 


Ver; A 


Actions 


1 3.1 Certificate Templates (evl-del.msl.dnslab.dnso... 

1 

2 
2 
1 
2 
1 
1 
1 
1 
1 
1 
1 
1 
2 
2 
4 
3 
2 
1 
1 
1 
1 
1 
1 
1 
1 
1 
2 



8. On the Windows 10 workstation, log on as the user that will receive the S/MIME Digital 
Signature certificate. Start certmgr.msc -> Personal -> right click: all tasks -> request new 
certificate. 

9. Select the Active Directory Enrollment Policy -> select the certificate template that was just 
created and follow the prompts. 

10. Once completed, the S/MIME digital signature certificate will be in the user's Personal -> 
Certificate store and can be used for S/MIME digital signature within Outlook. 

11. To configure Outlook to use the new S/MIME certificate: 

a. Open Outlook 2016. 

b. Click on File, and then Options. 

c. In the left-hand menu click on Trust Center. 

d. Click on the Trust Center Settings box. 
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Outlook Options 


X 


General 

Mail 

Calendar 

People 

Tasks 

Search 


t 


Help keep your documents safe and your computer secure and healthy. 


Security & more 

Visit Office.com to learn more about protecting your privacy and security. 
Microsoft Trustworthy Computing 


Microsoft Outlook Trust Center 


Language 
Advanced 
Customize Ribbon 
Quick Access Toolbar 
Add-ins 
| Trust Center 


The Trust Center contains security and privacy settings. These settings help keep your 
computer secure. We recommend that you do not change these settings. 


Jrust Center Settings... 


OK Cancel 


450 


451 


e. Click Email Security in the left-hand menu. 


Outlook Options 


General 

Mail 

Calendar 

People 

Tasks 

Search 

Language 

Advanced 

Customize Ribbon 

Quick Access Toolbar 

Add-ins 


Trust Center 


Help keep your documents safe and your computer secure and healthy. 

Security & more 

Visit Office.com to learn more about protecting your privacy and security. 

Microsoft Trustworthy Computing 

Microsoft Outlook Trust Center 

The Trust Center contains security and privacy settings. These settings help keep your 
computer secure. We recommend that you do not change these settings. 


Irust Center Settings... 


I 0K I 
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453 

454 

455 

456 

457 

458 


459 


f. Click the Settings button within the Encrypted Email section. 

g. Enter a name within the Security Settings Name field. 

h. Select the Signing Certificate by clicking on the Choose button for the signing 
certificate, and select the Hash Algorithm. 

i. If you have an S/MIME encryption certificate select the Choose button for the 
encryption certificate and select the Encryption Algorithm. 

j. Select the radio button Send these certificates with signed messages. 


Trusted Publishers 
Privacy Options 


Email Security 

Attachment Handling 
Automatic Download 
Macro Settings 
Programmatic Access 


Encrypted email 

* 


Security Setting Preferences 
Security Settings Name: 


□ Encrypt contents and attachments for outgoing messages 
I I Add digital signature to outgoing messages 
0 Send cleartext signed message when sending signed messages 
I I Request S/MIME receipt for all S/MIME signed messages 


My S/MIME Settings (pfox@ms1.dnslab.dnsops.gov) 


Digital IDs (Certificates) 

m 


Digital IDs or Certificates are documents that allow you to prove your identity 
Publish to GAL... I I Import/Export... | Get a Digital ID.,. I 


Read as Plain Text 

I I Read all standard mail in plain text 


0 AJIow script in shared folders 
I I Allow script in Public Folders 


Cryptography Format S/MIME 

0 Default Security Setting forthis cryptographic message format 
0 Default Security Setting for all cryptographic messages 
| Security Labels... | | New | | Delete | 
Certificates and Algorithms 
Signing Certificate: |PaulFox 

Hash Algorithm: 

Encryption Certificate: |pfox@ms1.dnslab.dnsops.gov | Choo 
Encryption Algorithm: AES (256-bit) 

0^nrtth«e Tralee w i th s i nner. - 


Windows Security 

Select a Certificate 


Paul Fox 

Issuer EV1-ISSUING 

Valid From: 9/30/2016 to 9/30/2017 


• Certificate Details 
General Details Certification Path 
Show: <Al> 


Field 

Value A 

^Authority Key Identifier 

Key ID =89 do f2 0 3 70 98 a5 5... 

§j]cRL Distribution Points 

[1]CRL Distribution Point: Distr... 

5TI Authority Information Access 

[1]Authority Info Access: Acc... 

|lv| Subject Alternative Name 

RFC822 Name=pfox@msl.dn... 

lb] Key Usage 

Digital Signature (80) 

Thumbprint algorithm 

shal 

|S| Thumbprint 

23 21 f6 27de 95 2f 16 69 a9 ... 
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.Appendix H Installation and Configuration of 
DNS Authority, DNS Cache, and DNS 
Signer at the NCCoE 

4 The NCCoE lab contained one DNS Signer appliance, and one VM instance each of DNS 

5 Authority and DNS Cache. These systems were not subject to special configurations beyond 

6 normal network configuration. The normal installation and setup for Secure64 products is 

7 found in the documentation (online at: https://support.secure64.com/). 

b There are no special configuration options needed for supporting DANE aware mail servers or 

? clients with Secure64 DNS products. DANE Resource Record types are treated as any other valid 

o DNS RRtype. 


„H.1 DNS Signer 

Once the DNS Signer appliance is installed and initially set up, there are no special configuration 
is options needed when deploying DANE to support email. Once a certificate is obtained (or 

14 generated) for the SMTP server, a TLSA RR needs to be generated and added to the zone. This 

is can be done using one of the tools or websites described in Section 3.4 above. Once the TLSA 

1 6 RR is generated, the zone can be manually updated by editing the zone file or updated via 

17 dynamic update. Enterprises should follow any established procedure. 


ia 11.2 DNS Authority 

19 Like DNS Signer, above, there is no difference between a standard setup of the authoritative 

20 server, and an authoritative server that hosts DANE RRtypes. Secure64 users should consult 

21 their product documentation on how to set up a DNS Authority instance. 


H.3 DNS Cache 

Like DNS Signer and DNS Authority, there are not additional steps in configuring a DNS Cache 
instance for supporting DANE. However, DANE requires the use of DNSSEC validation, so DNS 
Cache administrators (i.e. those that can enable the cachdnsadmin role) must enable DNSSEC 
validation and insure that the DNS Cache has a set of initial trust anchors. 
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